Concept Description#

In this section a concept for the Security Management will be discussed. Inputs for this concepts are mainly the requirements of ISO SAE 21434 Clause 5, 6 and 8.

The term security is used here synonymously for the term cybersecurity as defined in ISO SAE 21434.

Inputs#

  1. Stakeholders for the Security Management work products?

  2. Who needs which information?

  3. Which security plans do we have?

  4. Which other work products of security management are important?

  5. What tooling do we need?

Stakeholders for the Security Management#

  1. Project Lead (rl__project_lead)

    • approving security audit

    • planning of development for platform/nodule projects

    • status reporting of security activities

    • approving security plan, security package

  2. Security Manager (rl__security_manager)

  3. Committer (rl__committer)

    • creates and maintains SBOM

    • reports weaknesses and vulnerabilities

  4. Committer (rl__contributor)

    • reports weaknesses and vulnerabilities

  5. External Auditor (rl__external_auditor)

    • understand activities planning, processes definition and execution (needs review, if we consider that)

  6. “Distributor” (external role)

    • use the platform in a safe and secure way

    • integrate the platform in their product (distribution) and security package

    • plan this integration (also in time)

    • qualify the SW platform as part of his product

  7. Safety Manager (rl__safety_manager)

    • Supports activities

  8. Infrastructure/Tooling community (rl__infrastructure_tooling_community), Process community (rl__process_community), Process community (rl__security_team)

    • Supports the creation and maintenance of the SBOM

  9. Quality Manager (rl__quality_manager)

    • Supports training activities

Standard Requirements#

Also requirements of standards need to be taken into consideration:

  • ISO 26262

  • ASPICE

  • ISO SAE 21434

Security Management Plans#

This SW platform project defines two levels of planning: platform and module. There will be one security plan on platform level and several security plans on module level (one for each module). This is how we organize our development teams and repositories. Each of these security plan “creates” one component OoC. The Platform Security Plan (wp__platform_security_plan) exists only once and is part of the Platform Management Plan (wp__platform_mgmt) of the development project.

Security Management Work Products#

Apart from the security plans the main work products of security management are (see also the link to workflows below):

  • Security Manual (wp__platform_security_manual) - the security manual defines the requirements for safe and secure usage or integration of the SW platform (or its individual modules)

  • Reviews (wp__fdr_reports_security) - on security plan, security package and security analyses, according to ISO SAE 21434 requirements

  • Security Package (wp__platform_security_package) - the security package does not contain the security argumentation. By this the development project ensures it does not take over liability for the SW platform (or its individual modules). But it enables the distributors to integrate the SW platform (or its individual modules) in their security package.

Security Management Tooling#

For the security planning and security manual, “re-structured text” will be used for referencing.

For the activities planning and monitoring (who, when) we use Issue tracking system (wp__issue_track_system).

For the reporting (e.g. displaying the status of the work products) additional tooling is created (see Security Management Process Requirements).