diff --git a/docs/features/safety_planning/index.rst b/docs/features/safety_planning/index.rst index 963e596cf..171e82914 100644 --- a/docs/features/safety_planning/index.rst +++ b/docs/features/safety_planning/index.rst @@ -123,7 +123,7 @@ Feature Requirements Status --------------------------- .. needtable:: - :filter: docname is not None and "feature_example" in docname and "requirements" in docname + :filter: docname is not None and "feature_name" in docname and "requirements" in docname :style: table :types: feat_req :tags: feature_name diff --git a/docs/features/security_planning/index.rst b/docs/features/security_planning/index.rst index 94f440795..f9c94d3d0 100644 --- a/docs/features/security_planning/index.rst +++ b/docs/features/security_planning/index.rst @@ -16,7 +16,7 @@ ########################################## .. document:: [Feature Name] Security WPs - :id: doc__feature_example_security_planning_wp + :id: doc__feature_example_security_wp :status: draft :version: 1 :safety: ASIL_B @@ -91,7 +91,7 @@ Security Work Products List .. attention:: The above table must be updated according to your feature security planning. - - Fill the work producs links + - Fill the work products links Feature Security Package ======================== diff --git a/docs/module/manuals/safety_manual.rst b/docs/module/manuals/safety_manual.rst index 80de5f378..7bfb38aae 100644 --- a/docs/module/manuals/safety_manual.rst +++ b/docs/module/manuals/safety_manual.rst @@ -62,7 +62,7 @@ List of AoUs expected from the environment the platform / module runs on: results = [] for need in needs.filter_types(["aou_req"]): - if need and "environment" in need["tags"]: + if need and "environment" in need["tags"] and need["safety"] != "QM": results.append(need) .. attention:: @@ -90,7 +90,7 @@ This means for every feature the user selects, the platform safety manual and th results = [] for need in needs.filter_types(["aou_req"]): - if need and "environment" not in need["tags"]: + if need and "environment" not in need["tags"] and need["safety"] != "QM": results.append(need) .. attention:: diff --git a/docs/module/manuals/security_manual.rst b/docs/module/manuals/security_manual.rst index 5e1271d19..c14e1a6e7 100644 --- a/docs/module/manuals/security_manual.rst +++ b/docs/module/manuals/security_manual.rst @@ -64,18 +64,25 @@ List of AoUs expected from the environment the platform / module runs on: results = [] for need in needs.filter_types(["aou_req"]): - if need and "environment" in need["tags"]: + if need and "environment" in need["tags"] and need["security"] == "YES": results.append(need) +.. attention:: + Make sure these AoU are here for a security reason, i.e. every one "mitigates" a security analysis entry. + Assumptions on the User ^^^^^^^^^^^^^^^^^^^^^^^ | As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform OoC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform OoC security package. | Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: . Assumptions from components to their users can be fulfilled in two ways: | 1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (e.g. including appropriate security (access) control)" - in this case the AoU is marked as "platform". -| 2. There are assumption which can be fulfilled by a security control realized by some other Project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module OcC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe platform persistency feature. +| 2. There are assumption which can be fulfilled by a security control realized by some other Project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module OoC stand-alone - in this case the AoU is marked as "module". An example would be an "external API input" AoU which requires "The user shall provide input that has been validated/sanitized against injection and has not been tampered with in transit" - which is covered when using together with the platform's input validation / secure transport feature. List of AoUs on the user of the platform features or the module of this Security Manual: +Note: Platform security manual collects all platform wide AoU (have to be fulfilled by the user for any feature). +Module security manual collects all AoUs specific to a feature and its realizing components. +This means for every feature the user selects, the platform security manual and the related module manual has to be considered. + .. needtable:: :style: table :columns: title;id;status @@ -85,16 +92,39 @@ List of AoUs on the user of the platform features or the module of this Security results = [] for need in needs.filter_types(["aou_req"]): - if need and "environment" not in need["tags"]: + if need and "environment" not in need["tags"] and need["security"] == "YES": results.append(need) +.. attention:: + Make sure these AoU are here for a security reason, i.e. every one "mitigates" a security analysis entry. + Security concept of the OoC ---------------------------- | +Cybersecurity Claims and Residual Risk +-------------------------------------- + +For cybersecurity risks that were treated by "accept" or "share" in the module's TARA risk treatment decision (rather than mitigated by a cybersecurity requirement), the resulting cybersecurity claim and the residual risk are documented here. These claims are assumptions the integrator has to fulfil, or risks the integrator knowingly accepts, when using this module. + + + +Secure Configuration and Hardening +---------------------------------- + + + Security Weaknesses, Vulnerabilities ------------------------------------ -| Weaknesses, vulnerabilities (bugs in security relevant SW, detected by testing or by users, which could not be fixed) known before release are documented in the platform/module release notes . + +Weaknesses, vulnerabilities (bugs in security relevant SW, detected by testing or by users, which could not be fixed) known before release are documented in the platform/module release notes . + +Vulnerabilities discovered after release shall be reported via . + +Security Support +---------------- + + References ---------- diff --git a/docs/module/safety_mgt/module_safety_analysis_fdr.rst b/docs/module/safety_mgt/module_safety_analysis_fdr.rst index ccf1beffa..e33a083a0 100644 --- a/docs/module/safety_mgt/module_safety_analysis_fdr.rst +++ b/docs/module/safety_mgt/module_safety_analysis_fdr.rst @@ -21,7 +21,7 @@ :status: draft :version: 1 :safety: ASIL_B - :security: YES + :security: NO :realizes: wp__fdr_reports :tags: template diff --git a/docs/module/security_mgt/module_security_package_fdr.rst b/docs/module/security_mgt/module_security_package_fdr.rst index 24c487882..7054db2f7 100644 --- a/docs/module/security_mgt/module_security_package_fdr.rst +++ b/docs/module/security_mgt/module_security_package_fdr.rst @@ -39,7 +39,17 @@ The purpose of this review checklist is to report status of the formal review for the Security Package. -**2. Checklist** +**2. Conduct** + +As described in :need:`wf__p_formal_security_rv`, the formal document review is performed by an "external" security auditor, supported by the Security Manager: + +- reviewer: + +.. note:: + :need:`wf__p_formal_security_rv` is currently marked as "tailored out (needs discussion)" at process level. + Confirm with the Security Manager whether a formal review is actually performed for this Module before relying on this checklist. + +**3. Checklist** See also the review concept for further information about reviews in general and inspection in particular. @@ -49,34 +59,53 @@ See also the review concept for further information about reviews in general and * - Id - Security Package activity - Compliant to ISO SAE 21434? + - Reference - Comment * - 1 - Is a Security Package provided which matches the Security Plan (i.e. all planned work products referenced)? - [YES | NO ] + - :need:`[[title]] ` - * - 2 - - Is the argument how security is achieved, provided in the Security Package, plausible and sufficient? + - Is the argument how security is achieved (i.e. the Cybersecurity Case), provided in the Security Package, plausible and sufficient? - NO - - The argument is intentionally not provided by the Project. + - :need:`[[title]] ` + - The Cybersecurity Case argument is intentionally not provided in the Security Package by the Project (see :need:`wf__cr_mt_security_package`); it is covered by a dedicated work product, if created for the Module. * - 3 - Are the referenced work products available? - [YES | NO ] + - :need:`[[title]] ` - * - 4 - - Are the referenced work products in released state, including the Process Security Audit? - - NO - - Security Audit is currently not planned, tailored out. + - Are the referenced work products in released state, including the Cybersecurity Assessment report (ISO SAE 21434 clause 6.4.8)? + - [YES | NO ] + - :need:`[[title]] ` + - * - 5 + - Has the Organizational Cybersecurity Audit (ISO SAE 21434 clause 5.4.7) been performed, or is omitting it justified in the Security Plan's tailoring section? Note: this is distinct from the project-level Cybersecurity Assessment checked above. + - NO + - :need:`[[title]] ` + - The Organizational Cybersecurity Audit is currently tailored out at process level (:need:`wf__p_fs_audit_security`, needs discussion). + + * - 6 - If security related deviations from the process or security concept are documented, are these argued understandably? - [YES | NO ] + - :need:`[[title]] ` - - * - 6 - - Are the requirements for post-development available? + * - 7 + - Are the requirements for post-development available, together with the cybersecurity-relevant information needed for continued conformance (e.g. open weaknesses/vulnerabilities, verification/validation results)? + - [YES | NO ] + - :need:`[[title]] `, :need:`[[title]] ` + - + + * - 8 + - If off-the-shelf/third-party (OTS/OSS) components are part of the Module, is their cybersecurity qualification (e.g. maintenance status, CVE history, SBOM) documented? - [YES | NO ] + - :need:`[[title]] `, :need:`[[title]] ` - diff --git a/docs/module/security_mgt/module_security_plan.rst b/docs/module/security_mgt/module_security_plan.rst index 76a893fb9..41bc5512f 100644 --- a/docs/module/security_mgt/module_security_plan.rst +++ b/docs/module/security_mgt/module_security_plan.rst @@ -34,30 +34,82 @@ - Adjust ``status`` to be ``valid`` - Adjust ``safety`` and ``tags`` according to your needs +Security Management Context +============================ - | **1. Security Management Context** - | This Security Plan adds to the process security management guidance all the module development relevant work products needed for ISO SAE 21434 conformity. - | - | **2. Security Management Scope** - | This Security Plan's scope is a SW module of the SW platform /index.rst>. - | The module consists of one or more SW components and will be qualified as a OoC. - | - | **3. Security Management Roles** - - +---------------------------+--------------------------------------------------------------+ - | Security Manager | | - +---------------------------+--------------------------------------------------------------+ - | Project Manager | | - +---------------------------+--------------------------------------------------------------+ - - | **4. Tailoring** - | Additional to the tailoring in the SW platform project as defined in the process security management guidance we define here the additional tailoring on module level. - | - | - Excluded for this module are additionally the following work products (and their related requirements): - | - : - - | - | **5. Security Module Work Products** - | One set of work products for the module and one set for each component of the module: +This Security Plan adds to the process security management guidance all the module development relevant work products needed for ISO SAE 21434 conformity. + +Security Management Scope +========================== + +This Security Plan's scope is a SW module of the SW platform /index.rst>. +The module consists of one or more SW components and will be qualified as a Component Out-of-Context (OoC). + +Security Management Roles +========================== + +.. list-table:: Module roles + :header-rows: 1 + + * - Role + - Assignee + + * - Security Manager + - + + * - Project Manager + - + +Tailoring +========= + +Additional to the tailoring in the SW platform project as defined in the process security management guidance we define here the additional tailoring on module level. + +- Excluded for this module are additionally the following work products (and their related requirements): + + - : - + +Component Out-of-Context Assumptions +====================================== + +As this module is developed and qualified as a Component Out-of-Context (OoC), the following assumptions on its intended use, context and external interfaces are made. These assumptions are the basis for the module's cybersecurity requirements and shall be validated upon integration into an item or a higher-level component: + +- +- + +Off-the-Shelf / OSS Component Qualification +============================================= + +If off-the-shelf or Open Source Software (OSS) components are integrated into this module, their cybersecurity-relevant documentation is gathered and analysed to determine whether the allocated cybersecurity requirements can be fulfilled and whether the existing documentation is sufficient to support the cybersecurity activities. The following OTS/OSS components are planned to be qualified this way: + +- - - + +If the existing documentation is insufficient for a component, the cybersecurity activities necessary to close the gap are identified here: . + +Cybersecurity Assessment Decision +==================================== + +The decision whether a Cybersecurity Assessment is performed for this module, and the rationale for that decision, is documented here: + +- Decision: +- Rationale: +- If YES: responsible assessor, independent from the development team: + +Vulnerability Monitoring and Management +========================================== + +For this module, the following is defined for the continual cybersecurity activities after release: + +- Sources monitored for new cybersecurity information (e.g. advisories for used OTS/OSS components): +- SBOM generation: +- Vulnerability scan cadence: +- Triage and remediation responsible: +- Escalation to the cybersecurity incident response process: + +Security Module Work Products +============================== + +One set of work products for the module and one set for each component of the module: .. list-table:: Module Work Products :header-rows: 1 @@ -70,31 +122,31 @@ - WP status * - :need:`wp__module_security_plan` - - Security management guideline + - :need:`gd_guidl__security_plan_definitions` - - - this document - see above * - :need:`wp__module_security_package` - - Security management guideline + - :need:`gd_guidl__security_package` - - - - + - this document (including the linked documentation) - * - :need:`wp__fdr_reports_security` (Module Security Plan) - :need:`gd_chklst__security_plan` - - - - + - :need:`doc__mod_temp_module_name_security_plan_fdr` - * - :need:`wp__fdr_reports_security` (Module Security Package) - :need:`Security Package Formal Review Checklist ` - - - - + - :need:`doc__mod_temp_module_name_sec_pkg_fdr` - * - :need:`wp__fdr_reports_security` (Module's Security Analyses) @@ -115,21 +167,21 @@ - :need:`gd_temp__module_security_manual` - - - - + - :need:`doc__mod_temp_module_name_security_manual` - * - :need:`wp__verification_module_ver_report` - - Verification process guidance + - :need:`gd_temp__mod_ver_report` - - - - + - :need:`doc__mod_temp_verification_report` - * - :need:`wp__module_sw_release_note` - - Release management guidance + - :need:`gd_temp__rel_mod_rel_note` - - - - + - :need:`doc__mod_temp_module_name_release_note` - * - :need:`wp__module_user_manual` @@ -140,7 +192,7 @@ - * - :need:`wp__sw_module_sbom` - - Security management guidance + - :need:`gd_guidl__security_plan_definitions` - not started - - @@ -158,31 +210,31 @@ - WP status * - :need:`wp__requirements_comp` - - + - :need:`gd_temp__req_comp_req` - - - - + - :need:`doc__mod_temp_component_name_requirements` - * - :need:`wp__requirements_comp_aou` - - + - :need:`gd_temp__req_aou_req` - - - - + - :need:`doc__mod_temp_component_name_comp_sec_aou` - * - :need:`wp__requirements_inspect` - - + - :need:`gd_chklst__req_inspection` - - n/a - Checklist used in Pull Request Review - n/a * - :need:`wp__component_arch` - - + - :need:`gd_temp__arch_comp` - - - - + - :need:`doc__mod_temp_component_name_architecture` - * - :need:`wp__sw_component_security_analysis` @@ -193,36 +245,36 @@ - * - :need:`wp__sw_arch_verification` - - + - :need:`gd_chklst__arch_inspection_checklist` - - - - + - :need:`doc__mod_temp_component_name_arc_inspection` - * - :need:`wp__sw_implementation` - - + - :need:`gd_guidl__implementation` - - - - + - :need:`doc__mod_temp_component_name_detailed_design` & - * - :need:`wp__verification_sw_unit_test` - - + - :need:`gd_guidl__verification_guide` - - - - + - :need:`doc__mod_temp_verification_report` - * - :need:`wp__sw_implementation_inspection` - - + - :need:`gd_chklst__impl_inspection_checklist` - - - - + - :need:`doc__mod_temp_component_name_impl_inspection` - * - :need:`wp__verification_comp_int_test` - - + - :need:`gd_guidl__verification_guide` - - - - + - :need:`doc__mod_temp_verification_report` - diff --git a/docs/module/security_mgt/module_security_plan_fdr.rst b/docs/module/security_mgt/module_security_plan_fdr.rst index 6b4e9ff43..5ef819a64 100644 --- a/docs/module/security_mgt/module_security_plan_fdr.rst +++ b/docs/module/security_mgt/module_security_plan_fdr.rst @@ -39,7 +39,17 @@ The purpose of this review checklist is to provide a guidence for reviewing the Security Plans for each module. Each Module Security Plan shall have one checklist filled. -**2. Checklist** +**2. Conduct** + +As described in :need:`wf__p_formal_security_rv`, the formal document review is performed by an "external" security auditor, supported by the Security Manager: + +- reviewer: + +.. note:: + :need:`wf__p_formal_security_rv` is currently marked as "tailored out (needs discussion)" at process level. + Confirm with the Security Manager whether a formal review is actually performed for this Module before relying on this checklist. + +**3. Checklist** See also the review concept for further information about reviews in general and inspection in particular. @@ -49,76 +59,99 @@ See also the review concept for further information about reviews in general and * - Id - Security Plan activity - Compliant to ISO SAE 21434? + - Reference - Comment * - 1 - Is the rationale for the Security Work Products tailoring included? - [YES | NO ] + - :need:`[[title]] ` + :need:`[[title]] ` - * - 2 - Is impact analysis planned in case of re-use of SW (needed for every release following the first formal release)? - [YES | NO ] + - :need:`[[title]] ` + :need:`[[title]] ` + :need:`[[title]] ` - * - 3 - - Does the Security Plan define all needed activities for security management (including review and security audit)? + - Does the Security Plan define all needed activities for security management (including formal document review and security audit/assessment)? - [YES | NO ] - - + - :need:`[[title]] ` + :need:`[[title]] ` + - Security audit and assessment have no dedicated ``std_req`` modeled in the process description, only the related work products/workflows (:need:`wf__p_fs_audit_security`, :need:`wf__p_formal_security_rv`). * - 4 - Does the Security Plan define all needed activities for SW development, integration and verification? - [YES | NO ] + - :need:`[[title]] ` - * - 5 - - Does the Security Plan define all needed activities for security analysis? + - Does the Security Plan define all needed activities for security analysis (TARA)? - [YES | NO ] + - :need:`[[title]] ` - * - 6 - - Does the Security Plan define all needed activities for supporting processes (incl. tool mgt)? + - Does the Security Plan define all needed activities for supporting processes (incl. tool mgt, configuration and change management)? - [YES | NO ] + - :need:`[[title]] ` - * - 7 - Does the Security Plan document a responsible for all activities? - [YES | NO ] + - :need:`[[title]] ` - * - 8 - - If OSS software components is used, is it planned to be qualified? + - If OTS/OSS software components are used, is it planned to be qualified (e.g. maintenance status, CVE history, sufficiency of existing documentation)? - [YES | NO ] + - :need:`[[title]] ` + :need:`[[title]] ` - * - 9 - Is a Security Manager and a Project Lead appointed for the project? - [YES | NO ] + - :need:`[[title]] ` - * - 10 - Is Security Plan sufficiently linked to the Project Plan? - [YES | NO ] + - :need:`[[title]] ` - * - 11 - Is Security Plan updated iteratively to show the progress? - [YES | NO ] + - :need:`[[title]] ` - * - 12 - If Out-of-context software components is used, are the assumptions documented? - [YES | NO ] + - :need:`[[title]] ` + :need:`[[title]] ` + :need:`[[title]] ` - * - 13 - Does the Security Plan define all needed activities for SBOM generation? - [YES | NO ] + - :need:`[[title]] ` - * - 14 - Does the Security Plan define regular vulnerability scans for the generated SBOM? - [YES | NO ] + - :need:`[[title]] ` + :need:`[[title]] ` - .. note:: diff --git a/score/component_example/docs/security_analysis/aou_requirements.rst b/score/component_example/docs/security_analysis/aou_requirements.rst index 59fb9e151..87a23bfc2 100644 --- a/score/component_example/docs/security_analysis/aou_requirements.rst +++ b/score/component_example/docs/security_analysis/aou_requirements.rst @@ -51,7 +51,7 @@ Component AoU The Component User shall do xyz to use the component securely .. aou_req:: Another Title - :id: aou_req__mod_temp_component_name__another + :id: aou_req__mod_temp_component_name__sec_another :reqtype: Process :security: YES :safety: QM