Security Manual#

Note

Document header

[Your Module Name] Security Manual		status: draft security: YES safety: ASIL_B
tags: template version: 1 realizes: wp__module_security_manual

doc__mod_temp_module_name_security_manual		Generic Document

Attention

The above directive must be updated according to your Module.

Modify Your Module Name to be your Module Name
Modify id to be your Module Name in upper snake case preceded by doc__ and succeeded by _security_manual
Adjust status to be valid
Adjust security and tags according to your needs

Introduction/Scope#

Assumed Platform Security Requirements#

For the <Project platform / module name> the following security related stakeholder requirements are assumed to define the top level functionality (purpose) of the <Project platform / module name>. I.e. from these all the feature and component requirements implemented are derived.

Assumptions of Use#

Assumptions on the Environment#

The platform and its components are developed as Out of Context (OoC) with assumptions on the environment. It is assumed that the platform/components are integrated in a secure system, i.e. qualified POSIX OS. Also the HW related failures are taken into account by the system integrator, if not otherwise stated in the module’s security concept.

List of AoUs expected from the environment the platform / module runs on:

Title	ID	Status
Another Title	aou_req__mod_temp_crypto__sec_another	invalid
Build environment supports Rust 2021	aou_req__iav_primula__rust2021_build_env	valid
Crypto Environmental Requirement Example	aou_req__crypto__crypto_env_req_ex	invalid
pkcs11_dynload: Integrity and authenticity of the pkcs11 module	aou_req__crypto__sec_integ_auth_pkcs11_mod	valid
pkcs11_dynload: No use of ALLOW_PKCS11_LIB_OVERRIDE	aou_req__crypto__sec_no_pkcs11_lib_override	valid

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: <link to add>. 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 <Project> platform persistency feature.

List of AoUs on the user of the platform features or the module of this Security Manual:

Title	ID	Status
Crypto AoU Requirement Example	aou_req__crypto_aou__next_title	valid
Integrate as Rust library API	aou_req__iav_primula__rust_lib_api	valid
Next Title	aou_req__mod_temp_crypto__sec_next_title	invalid
pkcs11_dynload: pkcs11.h compatiblity	aou_req__crypto__sec_pkcs11_h_compatibility	valid

Security concept of the OoC#

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 <add link to release note>.

References#