“Common Criteria Vs. ISO 27001”
Security10thInformationICCC, Tromsø,22-24SystemsSeptember 2009“Common criteria vs. ISO 27001”jean-yves.bernard@thalesgroup.comlørdag 29. august 2009
Common criteria vs. ISO 27001 PlanHow to use an ISO/IEC 27001:2005 certified Information SecurityManagement System (ISMS) in a common criteria evaluation. Development environment in a CC evaluation (DVS)Developer point of view Evaluator point of view Information security management system (ISMS)and Risk AnalysisWhy an ISMS can be helpful to fulfill CC requirements ? Example (risk assessment/treatment) ISO/IEC 27001:2005 certified ISMSMethod to achieve an optimized CC DVS evaluation Gain on evaluation workloadThales ITSEF 2009 Conclusion2lørdag 29. august 2009
IntroductionThales ITSEF: HW & embedded SW ITSEF Under ANSSI agreement Convenor: Jean-Yves BERNARDEvaluator for 8 years Thales ITSEF technical manager Lead auditor ISO/IEC 27001:2005 (certified by LSTI) Risk manager ISO/IEC 27005:2008 (certified by LSTI)Thales ITSEF 2009 3lørdag 29. august 2009
Development environment in a CCevaluationThales ITSEF 2009Target Of Evaluation Life cycle4lørdag 29. august 2009
Development environment in a CCevaluationTarget Of Evaluation Life cycleTOE specTOE devTOE testingThales ITSEF 2009TOE personalisationEnd usage4lørdag 29. august 2009
Development environment in a CCevaluationTarget Of Evaluation Life cycle« Evaluated » Development environmentTOE specTOE devTOE testingThales ITSEF 2009TOE personalisationEnd usage4lørdag 29. august 2009
Development environment in a CCevaluationTarget Of Evaluation Life cycle« Evaluated » Development environmentTOE specTOE devTOE testingThales ITSEF 2009TOE personalisationEnd usage4lørdag 29. august 2009« Not evaluated » (covered by guidance)
Development environment in a CCevaluationTarget Of Evaluation Life cycle« Evaluated » Development environmentTOE spec Confidentiality of sensitive informationALC DVS, ALC DELTOE devTOE testingThales ITSEF 2009TOE personalisationEnd usage4lørdag 29. august 2009« Not evaluated » (covered by guidance)
Development environment in a CCevaluationTarget Of Evaluation Life cycle« Evaluated » Development environmentTOE spec Confidentiality of sensitive informationALC DVS, ALC DELTOE dev Integrity of the TOEALC DVS, ALC DEL, ALC CMCTOE testingThales ITSEF 2009TOE personalisationEnd usage4lørdag 29. august 2009« Not evaluated » (covered by guidance)
Development environment in a CCevaluationTarget Of Evaluation Life cycle« Evaluated » Development environmentTOE spec Confidentiality of sensitive informationALC DVS, ALC DELTOE dev Integrity of the TOEALC DVS, ALC DEL, ALC CMCTOE testingThales ITSEF 2009TOE personalisationEnd usage4lørdag 29. august 2009« Not evaluated » (covered by guidance)
Development environment in a CCevaluationThales ITSEF 2009Developer point of view (1/2)5lørdag 29. august 2009
Development environment in a CCevaluationDeveloper point of view (1/2)Thales ITSEF 2009 How can I know if I amready ?5lørdag 29. august 2009
Development environment in a CCevaluationDeveloper point of view (1/2)Thales ITSEF 2009 How can I know if I amready ?5lørdag 29. august 2009Perform a review of the CC requirements
Development environment in a CCevaluationDeveloper point of view (1/2) How can I know if I am readyFocus ?on ALC DVS:Thales ITSEF 2009“The developer shall produce anddocumentation”.ALC DVSx.1D5lørdag 29. august 2009Perform a review of the CC requirementsprovidedevelopmentsecurity
Development environment in a CCevaluationDeveloper point of view (1/2) How can I know if I am readyFocus ?on ALC DVS:Perform a review of the CC requirementsThales ITSEF 2009“The developer shall produce and provide development securitydocumentation”.ALC DVSx.1D. documentation shall describe all the security measures that arenecessary to protect the confidentiality and integrity of the TOEdesign and implementation ALC DVSx.1C5lørdag 29. august 2009
Development environment in a CCevaluationDeveloper point of view (1/2) How can I know if I am readyFocus ?on ALC DVS:Perform a review of the CC requirements“The developer shall produce and provide development securitydocumentation”.ALC DVSx.1D. documentation shall describe all the security measures that arenecessary to protect the confidentiality and integrity of the TOEdesign and implementation ALC DVSx.1C There is no method that completely helps a developer tobuild its development security documentation.Even if the CEM can be used as a guidance, it is notsufficient to help the developer.Thales ITSEF 2009 ALC DVS.2-25lørdag 29. august 2009
Development environment in a CCevaluationDeveloper point of view (1/2) How can I know if I am readyFocus ?on ALC DVS:Perform a review of the CC requirements“The developer shall produce and provide development securitydocumentation”.ALC DVSx.1D. documentation shall describe all the security measures that arenecessary to protect the confidentiality and integrity of the TOEdesign and implementation ALC DVSx.1C There is no method that completely helps a developer tobuild its development security documentation.Even if the CEM can be used as a guidance, it is notsufficient to help the developer.Thales ITSEF 2009 ALC DVS.2-2“I send all that I have to the evaluator and he will tell me if it is OK ornot”5lørdag 29. august 2009
Development environment in a CCevaluationDeveloper point of view (1/2) How can I know if I am readyFocus ?on ALC DVS:Perform a review of the CC requirements“The developer shall produce and provide development securitydocumentation”.ALC DVSx.1D. documentation shall describe all the security measures that arenecessary to protect the confidentiality and integrity of the TOEdesign and implementation ALC DVSx.1C There is no method that completely helps a developer tobuild its development security documentation.Even if the CEM can be used as a guidance, it is notsufficient to help the developer.Thales ITSEF 2009 ALC DVS.2-2“I send all that I have to the evaluator and he will tell me if it is OK ornot”5lørdag 29. august 2009
Development environment in a CCevaluationDevelopper point of view (2/2)Important risk of several iterations in the evaluationprocess.Thales ITSEF 2009 6lørdag 29. august 2009
Development environment in a CCevaluationDevelopper point of view (2/2) Important risk of several iterations in the evaluation process.Risk increased by environment “complexity”.Site 1Activity 1Site 2Activity 2TOE developmentenvironment scope.Activity 3Site 3Thales ITSEF 2009Activity 5Activity 4TOE6lørdag 29. august 2009
Development environment in a CCevaluationThales ITSEF 2009Evaluator point of view (1/2)7lørdag 29. august 2009
Development environment in a CCevaluationEvaluator point of view (1/2)Focus on ALC DVS:Thales ITSEF 2009” ALC DVSx-1: The evaluatordetermines what is necessary by first referring to the ST for anyinformation that may assist in the determination of necessaryprotection ”7lørdag 29. august 2009
Development environment in a CCevaluationEvaluator point of view (1/2)Focus on ALC DVS:Thales ITSEF 2009” ALC DVSx-1: The evaluatordetermines what is necessary by first referring to the ST for anyinformation that may assist in the determination of necessaryprotection ”ST7lørdag 29. august 2009
Development environment in a CCevaluationEvaluator point of view (1/2)Focus on ALC DVS:” ALC DVSx-1: The evaluatordetermines what is necessary by first referring to the ST for anyinformation that may assist in the determination of necessaryprotection ”Thales ITSEF 2009What Is necessaryST7lørdag 29. august 2009
Development environment in a CCevaluationEvaluator point of view (1/2)Focus on ALC DVS:” ALC DVSx-1: The evaluatordetermines what is necessary by first referring to the ST for anyinformation that may assist in the determination of necessaryprotection ” Actually, It is very difficult to determine “what is necessary”Thales ITSEF 2009What Is necessaryST7lørdag 29. august 2009
Development environment in a CCevaluationEvaluator point of view (1/2)Focus on ALC DVS:” ALC DVSx-1: The evaluatordetermines what is necessary by first referring to the ST for anyinformation that may assist in the determination of necessaryprotection ” Actually, It is very difficult to determine “what is necessary” The evaluator implicitly has to perform a development environmentvulnerability analysisThales ITSEF 2009What Is necessaryST7lørdag 29. august 2009
Development environment in a CCevaluationEvaluator point of view (1/2)Focus on ALC DVS:” ALC DVSx-1: The evaluatordetermines what is necessary by first referring to the ST for anyinformation that may assist in the determination of necessaryprotection ” Actually, It is very difficult to determine “what is necessary” The evaluator implicitly has to perform a development environmentvulnerability analysisSecuritydocumentationThales ITSEF 2009What Is necessaryOK/KO ?ST7lørdag 29. august 2009
Development environment in a CCevaluationEvaluator point of view (2/2) The CEM is generic, therefore evaluation work load is veryimpacted.Site 1Activity 1Site 2Activity 2TOE developmentenvironment scope.Activity 3Site 3Thales ITSEF 2009Activity 5Activity 4TOE8lørdag 29. august 2009
Development environment in a CCevaluationThales ITSEF 2009Other “issues”9lørdag 29. august 2009
Development environment in a CCevaluationOther “issues” CC do not require that a risk assessment is to beperformed But CC require some elements that are outputs of a riskassessment approach Thales ITSEF 2009 Security measuresSufficiency analysis (DVS.2 level).9lørdag 29. august 2009
Development environment in a CCevaluationOther “issues” CC do not require that a risk assessment is to beperformed But CC require some elements that are outputs of a riskassessment approach Security measuresSufficiency analysis (DVS.2 level). An Information Security Management System (ISMS) isnot requiredThales ITSEF 2009 But CC indirectly require a security policy ALC DVS.2-3 A security policy not managed by a recognized ISMS and notvalidated by the management could be not relevant.9lørdag 29. august 2009
ISMS/Risk AnalysisInformation Security Management Systemsolution stakeholder ersOrganizational controlsPolicyObjectivesThales ITSEF 2009Technical controls10lørdag 29. august 2009
ISMS/Risk AnalysisInformation Security Management Systemsolution An Information Security Management System (thatrespects a set of defined conditions) can be a « tool »that helps to correctly answer to DVS criteria.stakeholder ersOrganizational controlsPolicyObjectivesThales ITSEF 2009Technical controls10lørdag 29. august 2009
ISMS/Risk AnalysisThales ITSEF 2009Risk Analysis solution 11lørdag 29. august 2009
ISMS/Risk AnalysisRisk Analysis solution Thales ITSEF 2009 A risk analysis performed in the scope of an ISMS (thatrespects a set of defined conditions) can also be a« tool » that helps to correctly answer to DVS criteria.11lørdag 29. august 2009
ISMS/Risk Analysis (example)Thales ITSEF 2009Example:12lørdag 29. august 2009
ISMS/Risk Analysis (example)Thales ITSEF 2009Example:12lørdag 29. august 2009
ISMS/Risk Analysis (example)Example:Thales ITSEF 2009 An organization (company) develops a product andwants to obtain a certificate according to CC EAL4 (DVS.2 and VAN.5 level).12lørdag 29. august 2009
ISMS/Risk Analysis (example)Example:Thales ITSEF 2009 An organization (company) develops a product andwants to obtain a certificate according to CC EAL4 (DVS.2 and VAN.5 level).12lørdag 29. august 2009
ISMS/Risk Analysis (example)Example: An organization (company) develops a product andwants to obtain a certificate according to CC EAL4 (DVS.2 and VAN.5 level).Thales ITSEF 2009 The company has an ISMS:12lørdag 29. august 2009
ISMS/Risk Analysis (example)Example: An organization (company) develops a product andwants to obtain a certificate according to CC EAL4 (DVS.2 and VAN.5 level). The company has an ISMS: The TOE is developed in the scope of this ISMS. The company has an ISMS policy that takes into accountthe fact that products are under CC evaluation.The company ISMS answers to ISO/IEC 27001:2005requirementsThales ITSEF 2009 12lørdag 29. august 2009
Thales ITSEF 2009ISMS/Risk Analysis (example)13lørdag 29. august 2009
ISMS/Risk Analysis (example)Thales ITSEF 2009ISO 27001 provides the requirements that mustbe implemented by an ISMS.If these requirements are respected, this means firstthat the ISMS is correctly established.13lørdag 29. august 2009
ISMS/Risk Analysis (example)ISO 27001 provides the requirements that mustbe implemented by an ISMS.If these requirements are respected, this means firstthat the ISMS is correctly established.Thales ITSEF 2009RISK assessment / treatment13lørdag 29. august 2009
Thales ITSEF 2009ISMS/Risk Analysis (example)14lørdag 29. august 2009
ISMS/Risk Analysis (example) The company has performed a risk assessment with an identified methodology: 27005Thales ITSEF 2009 ISO/IEC 27001:2005 4.2.1 c) 1)14lørdag 29. august 2009
ISMS/Risk Analysis (example) The company has performed a risk assessment with an identified methodology: 27005 ISO/IEC 27001:2005 4.2.1 c) 1) with defined risk acceptance criteriaThe risk criteria take into account the fact that product underCC evaluation are developed in the scope of the ISMS ISO/IEC 27001:2005 4.2.1 c) 2)Thales ITSEF 2009 14lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel)Thales ITSEF 2009 ISO/IEC 27001:2005 4.2.1 d) & e)15lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)Thales ITSEF 2009asset15lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)Thales ITSEF 2009asset15lørdag 29. august 2009Supportive asset
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetThales ITSEF 2009Vulnerability15lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetVulnerabilityThales ITSEF 2009threats15lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetVulnerabilitythreatsThales ITSEF 2009Incident scenario15lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetVulnerabilitythreatsThales ITSEF 2009Incident scenarioRisk15lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetconsequence Asset value C,I impactCC (ST/PP) are taken into accountVulnerabilitythreatsThales ITSEF 2009Incident scenarioRisk15lørdag 29. august 2009
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetconsequence Asset value C,I impactCC (ST/PP) are taken into accountVulnerabilitythreatsThales ITSEF 2009Incident scenarioRisk15lørdag 29. august 2009Likelihood (VAN.5 level)
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetconsequence Asset value C,I impactCC (ST/PP) are taken into accountVulnerabilitythreatsThales ITSEF 2009Incident scenarioRisk15lørdag 29. august 2009Likelihood (VAN.5 level)
ISMS/Risk Analysis (example)Risk identification & Riskevaluation CC evaluation is taken into account (especially attackerlevel) ISO/IEC 27001:2005 4.2.1 d) & e)assetSupportive assetconsequence Asset value C,I impactCC (ST/PP) are taken into accountVulnerabilityLikelihood (VAN.5 level)threatsThales ITSEF 2009Incident scenarioRisk15lørdag 29. august 2009Risk level x
ISMS/Risk Analysis (example)Example risk evaluation criteriaThales ITSEF 2009“manager”)16lørdag 29. august 2009(chosen by the risk
ISMS/Risk Analysis (example)Example risk evaluation criteria“manager”) level of risk is estimatedThales ITSEF 2009 ISO/IEC 27001:2005 4.2.1 e) 3) ISO/IEC 27005:2008 8.2.2.316lørdag 29. august 2009(chosen by the risk
ISMS/Risk Analysis (example)Example risk evaluation criteria(chosen by the risk“manager”) level of risk is estimated ISO/IEC 27001:2005 4.2.1 e) 3) ISO/IEC 27005:2008 8.2.2.3threat likelihood(considering VAN.5 level)ease of vulnerability exploitation1 no consequence on TOE dev1 low1 very hard (above VAN.5 level)2 med on TOE dev2 med2 hard (VAN.5 level)3 high on TOE dev3 high3 easy (under VAN.5 level)Thales ITSEF 2009consequence(Asset value C,I impact )16lørdag 29. august 2009
ISMS/Risk Analysis (example)Example risk evaluation criteria(chosen by the risk“manager”) level of risk is estimated ISO/IEC 27001:2005 4.2.1 e) 3) ISO/IEC 27005:2008 8.2.2.3threat likelihood(considering VAN.5 level)ease of vulnerability exploitation1 no consequence on TOE dev1 low1 very hard (above VAN.5 level)2 med on TOE dev2 med2 hard (VAN.5 level)3 high on TOE dev3 high3 easy (under VAN.5 level)Thales ITSEF 2009consequence(Asset value C,I impact )16lørdag 29. august 2009
ISMS/Risk Analysis (example)Example risk evaluation criteria(chosen by the risk“manager”) level of risk is estimated ISO/IEC 27001:2005 4.2.1 e) 3) ISO/IEC 27005:2008 8.2.2.3threat likelihood(considering VAN.5 level)ease of vulnerability exploitation1 no consequence on TOE dev1 low1 very hard (above VAN.5 level)2 med on TOE dev2 med2 hard (VAN.5 level)3 high on TOE dev3 high3 easy (under VAN.5 level)Thales ITSEF 2009consequence(Asset value C,I impact )16lørdag 29. august 2009
ISMS/Risk Analysis (example)Example risk evaluation criteria(chosen by the risk“manager”) level of risk is estimated ISO/IEC 27001:2005 4.2.1 e) 3) ISO/IEC 27005:2008 8.2.2.3threat likelihood(considering VAN.5 level)ease of vulnerability exploitation1 no consequence on TOE dev1 low1 very hard (above VAN.5 level)2 med on TOE dev2 med2 hard (VAN.5 level)3 high on TOE dev3 high3 easy (under VAN.5 level)Thales ITSEF 2009consequence(Asset value C,I impact )16lørdag 29. august 2009
ISMS/Risk Analysis (example)Example risk evaluation criteria(chosen by the risk“manager”) level of risk is estimated ISO/IEC 27001:2005 4.2.1 e) 3) ISO/IEC 27005:2008 8.2.2.3threat likelihood(considering VAN.5 level)ease of vulnerability exploitation1 no consequence on TOE dev1 low1 very hard (above VAN.5 level)2 med on TOE dev2 med2 hard (VAN.5 level)3 high on TOE dev3 high3 easy (under VAN.5 level)Thales ITSEF 2009consequence(Asset value C,I impact )16lørdag 29. august 2009
ISMS/Risk Analysis (example)Example risk evaluation criteria(chosen by the risk“manager”) level of risk is estimated ISO/IEC 27001:2005 4.2.1 e) 3) ISO/IEC 27005:2008 8.2.2.3threat likelihood(considering VAN.5 level)ease of vulnerability exploitation1 no consequence on TOE dev1 low1 very hard (above VAN.5 level)2 med
“Common criteria vs. ISO 27001” jean-yves.bernard@thalesgroup.com 10th ICCC, Tromsø, 22-24 September 2009 lørdag 29. august 2009. Thales ITSEF 2009 2 Common criteria vs. ISO 27001 Plan How to use an ISO/IEC 27001:2005 certified Information Security Management System (ISMS) in a common criteria evaluation. Development environment in a CC evaluation (DVS) Developer point of view Evaluator .
ISO 27001:2013 published All ISO 27001:2005 certificates to have transitioned to ISO 27001:2013 30th September 2016 30th September 2015 No new ISO 27001:2005 certificates to be issued Initial audit to ISO 27001:2005 available Initial audit to ISO 27001:2013 available Transition to ISO 27001:2013 may be mandated by CB
1. Overview of ISO/IEC 27001:2022Information Security Management System 22 2. ISO/IEC 27001:2022 requirements 45 3. ISO/IEC 27001:2022Terms and Definitions 07 4. ISMS Documented information 18 5. ISO 27001 ISMS Internal auditing process 40 6. Steps for ISO 27001 certification 18 7. Risk management 18 8. Risk Assessment& Treatment 25 9.
ISO/IEC 27001:2005 has been superseded by ISO/IEC 27001:2013. The International Accreditation Forum (IAF) has announced that, as of 1 October 2014, no more accredited certificates to ISO 27001:2005 will be issued. From that date, certification bodies may only issue certificates to the new version of the Standard, ISO 27001:2013.
ISO 27001:2022. The new standard is more streamlined and easier to follow. What Happens to Organisations that Are Already Certified to ISO 27001:2013? Any current ISO 27001:2013 certificates are valid until they expire their 3-year lifetime. After it has expired, you will be assessed against ISO 27001:2022. For most, there is no rush to update
ISO/IEC 27001:2005 ISO/IEC 27002:2005 . ISMS Standards ISO/IEC 27001, 27002 . 23 / VSE-Gruppe 2013 . Standardization under ISO/IEC 27000 Standards Series in Cooperation with Additional Consortia . ISO/IEC 27001: Information Security Management System (ISMS) ISO/IEC 27002: Implementation Guidelines for ISO/IEC 27001 Con
ISO/IEC 27001:2013 is the first revision of ISO/IEC 27001. First and foremost, the revision has taken account of practical experience of using the standard: there are now over 17,000 registrations worldwide. However, there have been two other major influences on the revision. The first is an ISO requirement that all new and revised
A first look at the new ISO 27001:2013 Main changes in the new ISO 27002 2013 List of mandatory documents required by ISO 27001 (2013 revision) 3. Timing of the transition Companies already certified against the ISO/IEC 27001 2005 revision will have a
IELTS Academic Writing Task 2 Activity – teacher’s notes Description An activity to introduce Academic Writing task 2, involving task analysis, idea generation, essay planning and language activation. Students are then asked to write an essay and to analyse two sample scripts. Time required: 130 minutes (90–100 minutes for procedure 1-12. Follow up text analysis another 30–40 mins .
