What exactly is software security analysis analyzing?
-
Where do software bugs come from?
-
Is software security analysis really necessary?
-
What exactly does software security analysis analyze?
-
Should FTA or FMEA be used for software safety analysis?
-
How to perform software security analysis?
Q: What is the source of the software bug?
But specifically, systematic failures or bugs in software show different characteristics depending on the level of the software:
1
Software unit or function level:
Features : Strong certainty, easy to reproduce, easy to eliminate, mostly static characteristics.
2
Software architecture level:
Q: Is software security analysis really necessary?
But this conclusion is not entirely correct, or at least in actual operation, software security analysis is still necessary. I think the main reasons are :
1
As the complexity of automotive software continues to increase, the development of software components involves the collaborative work of multiple development teams. The interactions and dynamic attributes of software components are also becoming more complex. It is difficult to fully cover software failure issues with simple software safety development process constraints. .
2
Software failures at the system architecture level often have dynamic processes and are difficult to identify through software security development process constraints .
3
ISO 26262 Part 6 specifically defines the requirements for software safety analysis, which is also one of the new additions to the 2018 version.
4
The application of non-white-box models such as machine learning (AI) reduces the interpretability of software and increases the possibility of failure. Although architecture-based security analysis does not make non-white-box models completely interpretable, it helps analyze it from a logical level. Potential failure issues.
To sum up, software security analysis is still very necessary, especially for software systems with more complex or highly dynamic characteristics.
Q: What exactly is software security analysis analyzing?
In the previous first question "What are the sources of software bugs?", we talked about that software systemic failures mostly exist at two levels, namely the software unit and software architecture levels.
Since failures at the software unit level are mostly static in nature, they can basically be covered by process constraints. In addition, the security analysis workload at the software unit level is huge, and the actual operation feasibility is not high. Failures at the architecture level mostly involve running timing, data flow issues, etc., which have obvious dynamic characteristics and high complexity. The software security development process Constraints are not easy to detect and need to be further identified through security analysis, and corresponding security measures must be formulated to supplement and implement software security requirements. This time, iterations will be carried out to ultimately improve software security issues!
Therefore, the object of software security analysis is the software architecture, with the focus on analyzing the functional safety issues that may be caused by the dynamic characteristics of the architecture, rather than the syntax, logic and other errors at the code level of the specific software unit. Such software security analysis is more meaningful and practical .
As for the dynamic characteristics of software, the most common and important failure problem is the problem of interference between elements (FFI, Free From Inteference) caused by different ASIL levels, or the coexistence of safety and non-safety-related software, namely:
Therefore, during the software security analysis process, it is necessary to focus on the corresponding software security analysis based on the above issues.
So the next question is, the software architecture itself has different granularity. Which granularity should we analyze?
This issue is not stipulated in ISO 26262. I personally think this issue can be considered from two perspectives:
1
Based on the complexity of the software architecture, select a granularity that can be implemented within the project cycle. However, in order to ensure the effectiveness and completeness of the analysis, the granularity should not be too large.
2
In addition, it is important to note that security analysis at the software architecture level does not distinguish between different ASIL levels, and all ASIL levels must be performed!
Q: Should FTA or FMEA be used for software security analysis?
In ISO 26262, Part 6 Appendix E, it is mentioned that inductive or deductive methods can be used to identify design defects, conditions, faults or failures that can trigger a causal chain and lead to a violation of safety requirements.
In actual operation, it is recommended to use the inductive analysis method, namely FMEA (or STPA), mainly because :
1
FMEA's analysis process from cause to result is more suitable for the needs of software safety analysis, that is, using the software architecture as the basis for analysis to identify potential software failures.
2
There are no top-level failure goals similar to safety goals at the software level. Software safety analysis is not a process of detailing and decomposing safety requirements, but a supplementary examination of the deficiencies of the original design.
Q: How to perform software security analysis?
When talking about software security analysis earlier, inductive analysis methods are mostly used. Taking FMEA as an example, the basic security analysis steps remain the same,
but some steps are omitted. There are also certain differences in the specific execution process:
Step 1 : Determine the scope and object of analysis
Determine the object and scope of analysis, use software architecture input as the basis for security analysis, and select the appropriate software architecture granularity.
Software architecture needs to describe the static aspects of the relevant software (e.g., a block diagram representation showing functional elements and their interfaces/relationships) as well as the dynamic aspects (e.g., sequence diagrams, timing diagrams, scheduling diagrams, or statechart representations).
Safety analysis and associated failure analysis of software architecture can follow functional and/or processing chains, taking into account both static and dynamic aspects.
Step 2 : Software module structure analysis
List all software modules in the software architecture corresponding to the analysis object, and initially distinguish whether they are related to security.
It should be noted here that the software modules involved here not only include modules that have been assigned software security requirements, but also include normal functional software modules within the scope of analysis!
Step Three : Failure Mode Analysis
Analyze the failure modes of software modules one by one, where you can use guide words to generate questions to examine the specific functions or characteristics of the architectural elements. When using guide words, perform a safety-oriented analysis of the specific function or feature of each design element repeatedly using the guide words until all predetermined guide words have been examined.
Guidance words related to execution, scheduling or communication and corresponding possible failure examples are shown in the following figure:
Taking function O in the software architecture in step 1 as an example, by applying the guide words in the above table, the following software fault can be obtained:
Take this as an example to analyze the possible failures of all software modules. This step is also the most time-consuming part of the entire software security analysis process.
Step 4 : Develop safety improvement measures
Based on the failure modes identified in the previous step, formulate corresponding security improvement measures, derive corresponding software security requirements if necessary, and update the software architecture. Repeat the above steps until the probability of software failure is low enough!
京公网安备 11010802033920号