Synergies between the Common Criteria and Process Improvement

Please download to get full document.

View again

of 16
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Share
Description
Synergies between the Common Criteria and Process Improvement
Transcript
  Synergies between the Common Criteria and Process Improvement Miklós Biró, Bálint Molnár Corvinus University of Budapest {miklos.biro, balint.molnar}@informatika.uni-corvinus.hu Abstract.  This paper summarizes multifaceted synergies discovered between the ISO/IEC 15408 (Common Criteria) IT Security Evaluation standard, software product quality evaluation standards and the Capability Maturity Model Integration (CMMI ® ). In addition to serving research motivated interest, the usefulness of the synergies is demonstrated through case studies related to significant systems development projects. Keywords.  Security, Quality, Assessment, Evaluation, Capability, Maturity, Classification, Categorization 1   Introduction Security is naturally present in all systems of software product quality criteria, and  plays a significant role in the approporiate implementation of many software and systems engineering process areas. The development of the Information Society made this criterion of even higher significance, which resulted in the distinguished attention of international standardization bodies for example, resulting in the ISO/IEC 15408 (Common Criteria) standard. Certification needs and the constraints of the standardization process led to the flexibility in both the product standards (ISO/IEC 9126, ISO/IEC 14598) and the  process methodologies (CMMI ® , ISO/IEC 15504) which allows for evaluation modules based on a more elaborated background (ISO/IEC 15408, ISO/IEC 12207) as well as other modules based on simpler measurements. Even if some of the underlying standards evolved independently of each-other, the discovery of synergies between their structure can contribute to the establishment of a cost and resource effective multiple certification process [Taylor, Alves-Foss, Rinker, 2002]. The combination of software process and product quality standards has already  been studied in [Boegh, Régo, 2000]. In this paper we examine the synergies between the ISO/IEC 15408 (Common Criteria) standard and software quality and process capability evaluation methodologies. In addition to serving research motivated ®  CMMI is registered in the U.S. Patent & Trademark Office by Carnegie Mellon University  interest, the usefulness of the synergies is also demonstrated through case studies related to significant systems development projects. 2   The Common Criteria The history of the ISO/IEC 15408 (Common Criteria~CC) standard goes back to the 80's with the following non-exhaustive list of milestones: •   1980- TCSEC:  Trusted Computer System Evaluation Criteria (USA) •   1991 ITSEC: Information Technology Security Evaluation Criteria v 1.2 (France, Germany, the Netherlands, U.K.) •   1993 CTCPEC: Canadian Trusted Computer Product Evaluation Criteria v 3.0 •   1993 FC: Federal Criteria for Information Technology Security v 1.0 (USA) •      CC Editorial Board •   1996 CC v 1.0    ISO Committee Draft (CD) •   1998 CC v 2.0    ISO Committee Draft (CD) •   1999 CC v 2.1 =   ISO/IEC 15408  CC v 2.1 consists of the following parts: Part 1: Introduction and general model   Part 2: Security functional requirements   Part 3: Security assurance requirements   It is a common perception that understanding the Common Criteria (CC) evaluation  process requires painstakingly inspecting multiple documents and cross referencing innumerable concepts and definitions  [Prieto-Díaz, 2002]. The first challenge is the digestion of the abbreviations of which here is a brief extract for our immediate purposes: •   TOE: Target of Evaluation — An IT product or system and its associated administrator and user guidance documentation that is the subject of an evaluation. •   TSP: TOE Security Policy — A set of rules that regulate how assets are managed,  protected and distributed within a TOE. •   TSF: TOE Security Functions — A set consisting of all hardware, software, and firmware of the TOE that must be relied upon for the correct enforcement of the TSP. •   PP: Protection Profile — An implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs. •   ST: Security Target — A set of security requirements and specifications to be used as the basis for evaluation of an identified TOE. •   EAL: Evaluation Assurance Level — A package consisting of assurance components from Part 3 that represents a point on the CC predefined assurance scale. Figure 1 and Figure 2 give an overview of the CC evaluation context and process.    Fig. 1.  Evaluation context (Source: Common Criteria for Information Technology Security Evaluation Introduction and general model, August 1999 Version 2.1 ) Fig. 2.  TOE evaluation process (Source: Common Criteria for Information Technology Security Evaluation Introduction and general model, August 1999 Version 2.1)  Here is an illustrative list of the classes of security functional requirements discussed in Part 2 of the CC introducing more abbreviations: •   FAU  Security audit •   FCO  Communication •   FCS Cryptographic support •   FDP  User data protection •   FIA  Identification and authentication •   FMT  Security management •   FPR  Privacy •   FPT Protection of the TOE security functions •   FRU  Resource utilisation •   FTA  TOE access •   FTP  Trusted path / channels The following are classes of security assurance requirements discussed in Part 3: •   ACM  Configuration Management •   ADO  Delivery and Operation •   ADV  Development •   AGD  Guidance Documents •   ALC  Life Cycle Support •   ATE Tests •   AVA  Vulnerability Assessment •   AMA Maintenance of Assurance •   APE  Protection Profile Evaluation •   ASE Security Target Evaluation   And finally, table B.1 from Appendix B of Part 3 of CC v 2.1 which describes the relationship between the evaluation assurance levels and the assurance classes, families and components ( Table 2 ). 3   Enlightening Analogies The above sample from the CC naturally raises a lot of questions whose answers would require the already mentioned inspection and cross referencing of multiple documents including hundreds of pages. As an introductory alternative approach, the analogies below offer a shortcut to those who already have a basic understanding of models of software quality and process capability. CC certification is performed after the system is developed. In this sense, CC is closer to the software product quality evaluation standards ISO/IEC 9126, ISO/IEC 14598, and their follow-up being developed under the acronym SQUARE (ISO/IEC 25000 Software Quality Requirements and Evaluation) . As far as the ISO/IEC 9126 standard is concerned, the classes of security functional requirements and the classes of security assurance requirements are analogous to the high-level quality characteristics, while the requirement families to the subcharacteristics. Evaluation Assurance Levels (EAL) can be simply interpreted  as measurement results on an ordinal scale analogously to measurements of subcharacteristics in ISO/IEC 9126. A key concept of ISO/IEC 14598 is that of the evaluation module . "An evaluation module specifies the evaluation methods applicable to evaluate a quality characteristic and identifies the evidence it needs. It also defines the elementary evaluation  procedure and the format for reporting the measurements resulting from the application of the techniques." It also defines its own scope of applicability. In other words, an ISO/IEC 14598 evaluation module defines a consistent set of requirements and procedures for evaluating a quality characteristic independently from the concrete product, but depending on its application environment. If we consider the concept of Protection Profile (PP) as an implementation-independent set of security requirements for a category of TOEs that meet specific consumer needs, as introduced above, we can immediately see the analogy with the ISO/IEC 14598 evaluation module. Even-though CC certification is performed after the system is developed, its structure shows a striking analogy with the system of continuous and staged representation structures of the Capability Maturity Model Integration (CMMI ® ). In order to highlighting the analogy, let us consider Figure 3.5: Target Profiles and Equivalent Staging in the CMMI ®  for Development, Version 1.2 showing the process area capability level (CL) target profiles of the Continuous Representation making an organization's maturity level equivalent to a maturity level (ML) defined in the Staged Representation ( Table 3 ). Let us equivalently transform this table so that the last columns contain maturity levels instead of capability levels, and the cells underneath contain the capability level of the given process area necessary for achieving the given maturity level ( Table 5 ). The analogy between Table 2  and Table 5  is immediately apparent if we consider the following analogies of the concepts of the Common Criteria and of CMMI ( Table 1 ): Common Criteria CMMI Assurance Family Process Area Evaluation Assurance Level (EAL) Maturity Level Assurance value Capability Level Classification of Security Requirements Categorization of Process Areas Table 1.  Analogies of the concepts of the Common Criteria and of CMMI ®   This analogy not only helps those already familiar with CMMI to better understand the Common Criteria, but provides a new perspective on CMMI itself as well.
Advertisement
Related Documents
View more...
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks