9ICCC CC And CMMI-DEV - Common Criteria

CC and CMMIAn Approach to Integrate CCwith DevelopmentWolfgang PeterTÜV Informationstechnik GmbH- TÜViT -

Contents1. Status Quo2. CMMI for Development3. Striking Analogies4. Combining Standards5. Conclusion TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20081

What CC does accomplish .Ø assesses and rates security capabilities of IT productsØ establishes various levels of confidence in those productsØ offers flexibility for new type of products and configurations,and development modelsØ provides mutual recognition, i.e. dozens of countries andmany commercial users buy into working with CCØ . TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20082

. but .Ø uses a complex and somehow artificial “language”developers are not familiar withØ usually starts fairly late in the development processØ requires documents “just for CC”Ø focuses on product features, not on developmentprocessesØ . TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20083

Bottom lineØ CC is normally not integrated with developmentØ CC causes disruption from regular development processesØ CC often results in established coexistences of “normal”and “CC development” within organizationsØ CC is typically not institutionalized within an organization TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20084

Associated risksØ CC is normally not integratedwith developmentØ Decisions on a case by casebasisØ CC causes disruption fromregular development processesØ Unnecessary “overhead”Waste of time and moneyØ CC often results in establishedcoexistences of “normal” and“CC development” withinorganizationsØ No efficient re-usage ofdevelopment results(specifications, test results,development documents etc.)Ø CC is typically notinstitutionalized within anorganizationØ Heavy dependent on individualsNo guarantees that historicalresults can be repeated TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20085

In general .Ø The quality of a product is highly influenced by the quality of theprocesses used to acquire, develop, and maintain itSource: SEI, Mastering Process ImprovementØ Every organization involved in the development of security productswould basically benefit from experiences and best-practices of welldefined and structured engineering standards TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20086

Contents1. Status Quo2. CMMI for Development3. Striking Analogies4. Combining Standards5. Conclusion TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20087

Background Ø CMMI (Capability Maturity Model Integration) is a process improvement approachthat provides organizations with the essential elements of effective processesØ Successor of CMM or Software CMM; CMM developed from 1987 through 1997; releaseof CMMI, V1.1 in 2002Ø Created by members of industry, government and the SEI (Software EngineeringInstitute, Pittsburgh, PA, USA)Ø Three modelsØ CMMI for Development (CMMI-DEV), Version 1.2 (08/2006)Ø CMMI for Acquisition (CMMI-ACQ), Version 1.2 (11/2007)Ø CMMI for Services (CMMI-SVC), (2009)Ø Primary focus: process improvementØ Organizations cannot be CMMI “certified”, but are appraised and awarded a 1-5level rating (e.g., using SCAMPI - Standard CMMI Appraisal Method for ProcessImprovement)Ø Web Site: http://www.sei.cmu.edu/cmmi/ TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20088

Key conceptØProcessØ sequence of steps performed for agiven purposeØProcess Areas (PA)Ø characteristics of effectiveprocessesØSpecific/Generic Goals (SG/GG)Ø requirementsØSpecific/Generic Practices (SP/GP)Ø expected activitiesMaturity LevelProcess Area 1Capability Level (CL)Ø CL 0, CL 1, ., CL5 (cumulative)Ø PA specificØ CL i achievement of GG i in a PAØSpecificGoalsSpecificPractices.Process Area nGenericGoalsCapability LevelØProcess Area iinstitutionalization level2 types of representationsØ continuousØ stagedimplementation levelØ.GenericPracticesMaturity Level (ML)Ø ML 1, ML 2, ., ML 5 (cumulative)Ø pre-defined set of PAs, eachreaching a pre-defined CL TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 20089

Continuous representation:Process Areas by categories - 1ProcessManagementProjectManagementEngineering TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterSupportCC and CMMI-DEV, ICCC 2008Sep 200810

Continuous representation:Process Areas by categories - tIntegratedProjectManagementIntegrated Project alysisAnalysisDecisionAnalysisandDecision Analysis Causal Analysis and anizational Process tional InnovationandandDeploymentDeployment TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang equirementsDevelopmentRequirements ationValidationValidationCC and CMMI-DEV, ICCC 2008Sep 200811

Generic Goals 1-3ØGG 1 Achieve Specific GoalsØ GP 1.1Perform Specific PracticesØGG 2 Institutionalize a Managed ProcessØ GP 2.1Establish an Organizational PolicyØ GP 2.2Plan the ProcessØ GP 2.3Provide ResourcesØ GP 2.4Assign ResponsibilityØ GP 2.5Train PeopleØ GP 2.6Manage ConfigurationsØ GP 2.7Identify and Involve Relevant StakeholdersØ GP 2.8Monitor and Control the ProcessØ GP 2.9Objectively Evaluate AdherenceØ GP 2.10Review Status with Higher Level ManagementØGG 3 Institutionalize a Defined ProcessØ GP 3.1Establish a Defined ProcessØ GP 3.2Collect Improvement InformationProcess AreaGenericGoalsGenericPractices TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200812

OptimizingML 4Organizational Process PerformanceQuantitative Project ManagementQuantitatively ManagedRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process Definition IPPDOrganizational TrainingIntegrated Project Management IPPDRisk ManagementDecision Analysis and ResolutionRequirements ManagementProject PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product Quality AssuranceConfiguration ManagementGeneric Goal / Capability LevelML 3DefinedML 2Managed123Plus Critical SubprocessesML 5Organizational Innovation and DeploymentCausal Analysis and ResolutionPlus Critical SubprocessesStaged representation:Process Areas by Maturity Level45Source: method park, 2008 TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200813

Contents1. Status Quo2. CMMI for Development3. Striking Analogies4. Combining Standards5. Conclusion TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200814

Organizational ProcessPerformanceQuantitative Project ManagementRequirements DevelopmentTechnical SolutionProduct IntegrationVerificationValidationOrganizational Process FocusOrganizational Process Definition IPPDOrganizational TrainingIntegrated Project Management IPPDRisk ManagementDecision Analysis and ResolutionRequirements ManagementProject PlanningProject Monitoring and ControlSupplier Agreement ManagementMeasurement and AnalysisProcess and Product QualityAssuranceConfiguration ManagementGeneric Goal / Capability LevelOptimizingML 4Quantitatively ManagedML 3DefinedML 2Managed12 TÜV Informationstechnik GmbH – Member of TÜV NORD Group3Plus Critical SubprocessesML 5Organizational Innovation andDeploymentCausal Analysis and ResolutionPlus Critical SubprocessesLook and see!45Wolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200815

Analogy of key termsØ Process AreaØ Assurance FamilyØ PA CategoryØ Assurance ClassØ Capability LevelØ Assurance Component LevelingØ Maturity LevelØ EALØ AdditionØ ExtensionBoth, CMMI and CC, represent state of the artconcepts and culmination of decades of experiences TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200816

Contents1. Status Quo2. CMMI for Development3. Striking Analogies4. Combining Standards5. Conclusion TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200817

General ideaCC covers additional securityrelated requirements, for theproduct and the product’sdevelopment environment. (e.g. IEC 61508)Process Areas of CMMI-DEV cover demands onplanned and controllable product developmentAn organization develops products with different requirements onfunctionality, security, and . (e.g. safety) TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200818

Example: ALC CMS (CM Scope)Achievement ofprocess relatedrequirementsInstitutionalization ofthis PA within theorganizationConfiguration ManagementConfiguration ManagementALC CMS.4: ProblemGeneric Goals & PracticesSpecific Goals & Practicestracking CM coverageGG 1 Achieve Specific GoalGP 1.1 Perform Specific PracticesSG 1 Establish BaselinesSP 1.1 Identify Configuration ItemsSP 1.2 Establish a ConfigurationManagement SystemSP 1.3 Create or Release BaselinesGG 2 Institutionalize a Managed ProcessGP 2.1 Establish an Organizational PolicyGP 2.2 Plan the ProcessGP 2.3 Provide ResourcesGP 2.4 Assign ResponsibilityGP 2.5 Train PeopleGP 2.6 Manage ConfigurationsGP 2.7 Identify and Involve RelevantStakeholdersGP 2.8 Monitor and Control the ProcessGP 2.9 Objectively Evaluate AdherenceGP 2.10 Review Status with Higher LevelManagementGG 3 Institutionalize a Defined ProcessGP 3.1 Establish a Defined ProcessGP 3.2 Collect Improvement Information TÜV Informationstechnik GmbH – Member of TÜV NORD GroupSG 2 Track and Control ChangesSP 2.1 Track Change RequestsSP 2.2 Control Configuration ItemsSG 3 Establish IntegritySP 3.1 Establish ConfigurationManagement RecordsSP 3.2 Perform Configuration AuditsALC CMS.4.1C The configuration list shallinclude the following: the TOE itself; theevaluation evidence required by the SARs;the parts that comprise the TOE; theimplementation representation; andsecurity flaw reports and resolutionstatus.ALC CMS.4.2C The configuration list shalluniquely identify the configuration items.ALC CMS.4.3C For each TSF relevantconfiguration item, the configuration listshall indicate the developer of the item.CC EAL4 specificrequirementsWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200819

Activities and (first) resultsØ Focused on EAL4Ø Bi-directional “mapping” and parts of the integration CC/CMMI-DEVdoneØ EAL4 does not require any addition of new CMMI-DEV process areasØ CMMI-DEV specific goal needs to be added (à ALC DVS)Ø Lots of additions to specific practices in engineering, projectmanagement, and support will be neededØ Lots of additions to the CMMI-DEV informative material necessary TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200820

Contents1. Status Quo2. CMMI for Development3. Striking Analogies4. Combining Standards5. Conclusion TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200821

Conclusion and next stepsØ Experience shows that efficiently developing high quality/securityproducts requires managing the engineering processesØ In this respect CC needs to evolve or be combined with engineeringstandardsØ Combining CMMI-DEV and CC is feasibleØ e.g. EAL4 would require Capability Level 3 of quite a few CMMIProcess AreasØ Piloting with customers will followØ Models will be implemented in a web based tool, supportingØ reference modelsØ process definitionØ management TÜV Informationstechnik GmbH – Member of TÜV NORD GroupWolfgang PeterCC and CMMI-DEV, ICCC 2008Sep 200822