Concept Description

Security Analysis Concept		status: valid
tags: security_analysis relates to: wf__analyse_sec_platform_featarch, wf__analyse_sec_featarch, wf__analyse_sec_comparch, wf__mr_sec_analyses, wf__vy_sec_analyses
doc_concept__security_analysis		Concept Definition

This section discusses a concept for Security Analysis. Different methods for Security Analysis are used (e.g. STRIDE). Inputs for this concept are the requirements of ISO/SAE 21434 Part 8 and Part 15.

The objective of the Security Analysis is to identify and analyze potential cybersecurity threat scenarios, threats and vulnerabilities. Security Analysis identifies potential attack scenarios that could compromise the cybersecurity of the defined elements. How to perform a Security Analysis is described in Security Analysis Guideline (gd_guidl__security_analysis). To have a structured Security Analysis, the threat scenarios have to be considered Security Analysis threat sc... (gd_guidl__sec_ana_threat_scenarios). These are separated into the following categories:

- Attack surfaces threats: Interfaces and entry points that could be exploited by attackers.

- Communication threats: Threats related to data transmission including interception, manipulation, or spoofing.

- Shared information inputs threats: Same information input used by multiple functions that could be exploited.

- Unintended impacts threats: Security impacts due to various vulnerabilities like privilege escalation or resource exhaustion.

- Development threats: Vulnerabilities that occur during the development process, potentially leading to security issues.

The objective of the Security Analysis is to show that the architecture created to fulfill the requirements does not introduce possible vulnerabilities which would break the security requirements (cybersecurity goals are top level security requirements). Or rather that the possibility of these vulnerabilities is reduced to an acceptable level. This can be done by mitigation (accept, avoid, reduce, share). The Security Analysis is used to find possible threats and their effects. The possible threats are systematically identified by applying threat models STRIDE Threat Model (gd_guidl__threat_models_stride).

The Security Analysis shall be performed once at platform level to analyze the attack surfaces between the features of the platform. Typically the Security Analysis shall be performed at feature level and component level. If a component has no sub-components, the result of the analysis is the same as at feature level. So no additional consideration is needed. In this case please document this in the content of the document.

Inputs

1. Stakeholders for the Security Analysis?

2. Who needs which information?

3. How to analyze?

4. How to mitigate?

5. What analysis shall be done in which level?

Stakeholders for the Security Analysis

1. Security Engineer (rl__security_engineer)

   • Analyze all the feature architectures together with a Platform Security Analysis

   • Analyze the feature architecture with the defined method

   • Analyze the component architecture with the defined method

   • Monitor/verify the Security Analyses

2. Security Manager (rl__security_manager)

   • Approve the Security Analysis

   • Approve the verification of the Security Analyses

3. Contributor (rl__contributor)

   • Support the Security Analysis

   • Support the monitoring and verifying of the Security Analyses

4. Committer (rl__committer)

   • Support the Security Analysis

   • Support the monitoring and verifying of the Security Analyses

5. Safety Manager (rl__safety_manager)

   • Support the Security Analysis

   • Support the monitoring and verifying of the Security Analyses

Standard Requirements

Also requirements of standards need to be taken into consideration:

• ISO/SAE 21434

• ISO 26262

How to analyze?

The Security Analysis are done on the feature and component architecture. The Security Analysis shall be done accompanying to the development. So the results can directly be used for the development of the feature and component. With an iterative approach it is needed to provide the evidence of the cybersecurity of the functions. The analysis were applied at static and dynamic architecture diagrams. Examples will be added here in an future PR (eclipse-score/process_description#409).

How to mitigate?

Identified risks without a mitigation remain open and are tracked in the issue tracking system Issue tracking system (wp__issue_track_system) until they are resolved. Resolving includes acceptance of the risk or avoidance. Further a new security control may be needed to reduce the risk. Finally also the risk may shared, if applicable.

What analysis shall be done in which level?

The Security Analysis shall consider the architectural elements on different levels.

1. Platform Level: The Security Analysis shall be performed once at platform level to analyze the attack surfaces between the features of the platform.

2. Feature Level: This level involves a more detailed analysis of individual components within the feature. The analysis shall consider the internal structure of components and their interactions with other components in the feature.

3. Component Level: If a component consists of multiple sub-components, the analysis shall be extended to these sub-components. This level of detail is necessary to identify specific threat models that may not be apparent at higher levels.