Security Analysis Guidelines#
Security Analysis Guideline
|
status: valid
|
||||
This document describes the general guidance for Security Analysis based on the concept which is defined Security Analysis Concept (doc_concept__security_analysis). Use the platform Security Analysis as an input so that general security controls are only defined once and not in every single Security Analysis.
Workflow for Security Analysis#
The workflow of the Security Analysis is described in Security Analysis Workflows. The single steps in these workflows are described in detail in the following sections.
Step-by-Step-approach Security Analysis Feature/Component:#
The analysis is done by using the template Security Analysis Threat Templates on the feature or component architectural diagrams. By using the threat models <STRIDE Threat Model (gd_guidl__threat_models_stride)> it can be ensured that the analysis is done in a structured way. Apply the threat model to the diagram and document the results in the template. Use the content of the document Feature Threat Template (gd_temp__feat_sec_ana_threat), Component Threat Template (gd_temp__comp_sec_ana_threat) to describe e.g. why a threat model is not applicable for the diagram. If a treat can’t be applied, the reason has to be documented in the content of the document, so it can be recognized.
The attributes of the template are described in Process Security Analysis Attributes.
Steps:
For each of the security functions realized by an architecture element check if a threat from the threat model STRIDE Threat Model (gd_guidl__threat_models_stride) applies.
If a threat model applies, use the template Feature Threat Template (gd_temp__feat_sec_ana_threat) or Component Threat Template (gd_temp__comp_sec_ana_threat) to perform the analysis.
The title of the analysis should be easily recognizable e.g. “Component xy unauthorized access”.
Link the violated architecture with the “violates” attribute.
Replace the placeholders in the “id” attribute with the name of the feature or component and a short description of the element so that it can be easily identified.
Document the threat ID from the threat model STRIDE Threat Model (gd_guidl__threat_models_stride) that applies to the element in the “threat_id” attribute.
Describe the threat effect of the threat model on the element in the “threat_effect” attribute. Use the threat description and enlarge it if it’s applicable to the considered element.
Document the mitigation. This can be (accept, avoid, reduce, share) of the threat.
If there is no mitigation or existing mitigation is not sufficient, a mitigation issue has to be created in the Issue Tracking system and linked in the “mitigation_issue” attribute.
The analysis is finished if for each identified threat a sufficient mitigation exists.
Unless the attribute sufficient is yes, mitigation and argument attributes can be still empty.
Continue the analysis until all applicable threat models are checked.
The verification is done by applying the checklist Security Analysis Checklist... (gd_chklst__security_analysis).
Note
If there are changes they have to be analyzed with an impact analysis Impact Analysis Template (gd_temp__change_impact_analysis). If needed the Security Analysis has to be updated accordingly. Therefore all necessary steps have to be repeated.
Step-by-Step-approach Security Analysis Platform:#
The analysis is done by using the template Security Analysis Threat Scenario Templates on the platform diagrams using a list of threat scenarios <Security Analysis threat sc... (gd_guidl__sec_ana_threat_scenarios)>. Use the content of the document Platform Security Analysis ... (gd_temp__plat_threat_scenario), Feature Threat Template (gd_temp__feat_sec_ana_threat) or Component Threat Template (gd_temp__comp_sec_ana_threat) to describe e.g. why a threat scenario is not applicable for the diagram. If a threat scenario can’t be applied, the reason has to be documented in the content of the document, so it can be recognized.
The attributes of the template are described in Process Security Analysis Attributes.
Steps:
For each architectural element check if a threat from the threat scenarios Security Analysis threat sc... (gd_guidl__sec_ana_threat_scenarios) applies.
If a threat scenario applies, use the template Platform Security Analysis ... (gd_temp__plat_threat_scenario), Feature Threat Template (gd_temp__feat_sec_ana_threat) or Component Threat Template (gd_temp__comp_sec_ana_threat) to perform the analysis.
The title of the analysis should be easily recognizable e.g. “Component xy unauthorized access”.
Link the violated architecture with the “violates” attribute.
Replace the placeholders in the “id” attribute with the name of the feature or component and a short description of the element so that it can be easily identified.
Document the threat ID from the threat scenario Security Analysis threat sc... (gd_guidl__sec_ana_threat_scenarios) that applies to the element in the “threat_id” attribute.
Describe the threat effect of the threat scenario on the element in the “threat_effect” attribute. Use the violation cause description and enlarge it if it’s applicable to the considered element.
Document the mitigation. This can be (accept, avoid, reduce, share) of the threat.
If there is no mitigation or the mitigation is not sufficient, a mitigation issue has to be created in the Issue Tracking system and linked in the “mitigation_issue” attribute.
The analysis is finished if for each identified threat a sufficient mitigation exists.
Unless the attribute sufficient is yes, mitigation and argument attributes can be still empty.
Continue the analysis until all applicable threat scenarios are checked.
The verification is done by applying the checklist Security Analysis Checklist... (gd_chklst__security_analysis).
Note
If there are changes they have to be analyzed with an impact analysis Impact Analysis Template (gd_temp__change_impact_analysis). If needed the Security Analysis has to be updated accordingly. Therefore all necessary steps have to be repeated.
Examples for Security Analysis at feature level#
future PR (eclipse-score/process_description#409).
Examples for Security Analysis at component level#
future PR (eclipse-score/process_description#409).