A safety analysis method based on a failure deviation matrix

Abstract

The present invention belongs to the field of software security, and specifically relates to a security analysis method based on a failure deviation matrix to meet the requirements of software security analysis for aviation equipment. First, consider the cross-linking relationship between software systems, establish a system model, identify each scenario describing functions in the model, generate a failure deviation matrix in combination with failure analysis rules, determine failure modes, and conduct tracking and monitoring analysis on the entire failure process in the model to form a standardized software security analysis method for aviation equipment. A method for generating a failure deviation matrix of aviation equipment software based on a safety-oriented model is established, which improves the effectiveness and accuracy of security analysis, avoids subjectivity and arbitrariness in security analysis, is intuitive and has clear meaning, and is convenient for engineers to understand and operate; a standard and operable software security analysis process is established to make the software security analysis work more standardized, complete and operable.

Description

Technical Field

[0001] The present invention belongs to the field of software security, and particularly relates to a security analysis method based on a failure deviation matrix. Background Art

[0002] The proportion of critical software in aviation equipment has increased significantly. Once these safety-critical software fail, it will cause immeasurable losses. However, there are still many problems when existing software security analysis methods are used for the security analysis of aviation equipment software, mainly including insufficient analysis, lack of pertinence, difficulty in qualitative analysis, strong subjectivity, etc.

[0003] Although relevant research has been carried out on software security analysis methods for aerospace equipment at home and abroad, common software security analysis methods such as FMEA and FTA mainly rely on personnel experience when analyzing equipment software, and it is difficult to conduct qualitative analysis. When analyzing the security of the same analysis object by analysts with different experiences, it is impossible to ensure its consistency and sufficiency. Therefore, traditional methods are not fully applicable to aviation equipment and cannot effectively discover potential security problems in aviation equipment software.

[0004] To improve the security and quality level of aviation equipment software, meet security requirements, ensure the full implementation of work such as the identification of software failure modes, cause and effect analysis, and control measure analysis in aviation equipment software, and realize the true implementation of the security requirements of aviation equipment software, it is very necessary and urgent to design a security analysis method for the operation scenario of aviation equipment software. Summary of the Invention

[0005] Aiming at the deficiencies of traditional security analysis technologies, the purpose of the present invention is to propose a method for generating a software failure deviation matrix for aviation equipment to meet the requirements of aviation equipment software security analysis.

[0006] The technical solution of the present invention:

[0007] A security analysis method based on a failure deviation matrix, comprising the following steps:

[0008] Step 1: Construct a software model oriented to security

[0009] According to the software requirement document, conduct requirement analysis, determine the functions of the modeling object, interactive devices, and external interfaces, and construct a use case diagram, activity diagram, sequence diagram, and state diagram. Decompose the requirements to divide the system use cases, and identify the interactive objects related to the use cases to form a use case diagram; for each use case, analyze the activity flow of the use case to form an activity diagram; combine the activity diagram, analyze the activity timing, and at the same time define the interaction relationship between the system and external interactive objects to form a sequence diagram; analyze the system running state and draw a system state diagram.

[0010] Step 2: Determine the analysis object and object elements

[0011] Based on the interaction scenarios between each system in the use case diagram in Step 1 and the outside world, select and determine the analysis object; for the determined analysis object, refer to the sequence diagram and state diagram, and use the state parameters as the elements of the security analysis object; the state parameters include messages, state transition conditions, and processing procedures.

[0012] Step 3: Determine the failure analysis rules

[0013] According to the functional scenarios of the analysis object, determine the failure analysis rules for the object elements. The analysis rules include time constraint rules: occurring earlier than the specified time, occurring later than the specified time; sequence constraint rules: occurring before the specified action, occurring after the specified action; state constraint rules: abnormal message value, missing message.

[0014] Step 4: Generate a deviation matrix

[0015] For the characteristics of the equipment software, cross - combine the security analysis object elements determined in Step 2 and the analysis rules determined in Step 3 to represent the deviations of the design intent, and form a deviation matrix.

[0016] Step 5: Deviation injection model

[0017] Inject each deviation in the deviation matrix formed in Step 4 into the software model established in Step 1. Through the operation of the model and the transition of the state diagram, analyze whether each deviation causes software failure and determine the impact of the failure on the system.

[0018] Step 6: Propose security requirements or recommended measures

[0019] Based on the various deviations in the deviation matrix and the impact on the system after the deviation injection model, determine the possible causes and consequences of the failure, propose security requirements or recommended measures, and verify them in the software model established in Step 1.

[0020] Step 7: Sufficiency check

[0021] Conduct a sufficiency check on the input, output, and processing procedures of the software to be analyzed, and check whether the security analysis coverage rate reaches 100%.

[0022] Furthermore, the scenario in Step 2 specifically refers to the interaction scenario between the system and the outside world, which can be expressed by use case diagrams and sequence diagrams. The goal is to extract system use cases, conduct requirements analysis, then perform system function analysis based on activities, timings, and states, and finally verify the system logic by running the model.

[0023] Further, the messages in step 2 refer to the messages sent and received between objects in the sequence diagram; the state transition conditions refer to the behavioral actions that need to be executed to reach the states specified by the system; the processing process refers to the process of analysis objects after receiving messages and before sending messages;

[0024] Further, the anomalies in step 3 refer to the transmitted information containing error values; the omissions refer to the failure to provide interactive services as required; the redundancies refer to the provision of services not required. The analysis rules also include other operations that do not meet the design intent; they can be customized according to the software characteristics to expand the application scenarios.

[0025] Further, the characteristics of the equipment software in step 4 refer to the need to select analysis rules suitable for the current analysis software according to the software characteristics and combine them with the analysis objects.

[0026] Further, in step 4, the security analysis objects determined in step 2 and the analysis rules determined in step 3 are cross-combined to represent the deviations in the operating state, forming a deviation matrix. The deviation matrix is the input for software failure analysis.

[0027] Further, the impacts generated by the system in step 6 are divided into catastrophic, severe, medium, and mild; among them, the catastrophic impact means the loss of key functions of the system where the software is located or the destruction of the system; the severe impact means the serious degradation of the key functions of the system where the software is located; the medium impact means the general degradation of the key functions of the system where the software is located and the loss of general functions; the mild impact means the impact lighter than the previous three categories and does not affect the completion of the functions of the system where the software is located.

[0028] Further, the security requirements in step 6 will run through every stage of the software R & D process, and it is necessary to track them in each stage of software design, coding, and verification to ensure that the security of the software meets the system requirements.

[0029] Further, if the security analysis coverage rate checked in step 7 does not reach 100%, then return to step 4 to check the integrity of the deviation matrix.

[0030] Advantages of the present invention:

[0031] a) Established a method for generating a software failure deviation matrix of aviation equipment based on a security-oriented model, improving the effectiveness and accuracy of security analysis, avoiding subjectivity and arbitrariness in security analysis, with an intuitive method and clear meaning, facilitating the understanding and practical operation of engineering personnel; established a standard and operable software security analysis process, making the software security analysis work more standardized, complete, and operable.

[0032] b) Analyze the software failure situation by combining the operation scenarios and failure rules of aviation equipment software. Starting from the requirements represented in text and delving deeper layer by layer into the system requirements represented in models, conduct failure rule analysis on the object elements in sequence diagrams and state diagrams to obtain a relatively comprehensive failure deviation matrix. Inject the deviations into the scenario model to analyze the impacts of failures, and give safety requirements or control measures in the early stage of software development, which has good engineering practical significance and can be used as a reference for the design of similar critical systems in the future, thus effectively improving the safety of the overall equipment software. Description of the Drawings

[0033] Figure 1 Software safety analysis process based on the failure deviation matrix;

[0034] Figure 2 Flowchart of the method for generating a software failure deviation matrix for aviation equipment. Detailed Implementation Manner

[0035] Next, in combination with the drawings in the embodiments of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0036] Aiming at the deficiencies of traditional safety analysis technologies, the purpose of the present invention is to propose a method for generating a software failure deviation matrix for aviation equipment to meet the requirements of aviation equipment software safety analysis. First, consider the cross-linking relationships between software systems, establish a system model, identify each scenario describing functions in the model, generate a failure deviation matrix in combination with failure analysis rules, determine the failure modes, and conduct tracking and monitoring analysis on the entire failure process in the model to form a standardized safety analysis method for aviation equipment software.

[0037] The method includes the following steps:

[0038] a) Construct a safety-oriented software model;

[0039] b) Determine the analysis object;

[0040] c) Determine the failure analysis rules;

[0041] d) Generate the deviation matrix;

[0042] e) Inject the deviations into the model;

[0043] f) Propose safety requirements or recommended measures;

[0044] g) Conduct sufficiency check.

[0045] The specific principle of the software failure deviation matrix generation method for aviation equipment provided by the present invention is as follows:

[0046] Step 1: Construct a safety-oriented software model

[0047] Based on the software requirement document, conduct requirement analysis to determine the functions of the modeling object, interactive devices, and external interfaces, and construct a use case diagram, activity diagram, sequence diagram, and state diagram. Decompose the requirements to divide the system use cases, and identify the interactive objects related to the use cases to form a use case diagram; for each use case, analyze the activity flow of the use case to form an activity diagram; combine the activity diagram, analyze the activity timing, and at the same time define the interaction relationship between the system and external interactive objects to form a sequence diagram; analyze the system running state and draw the system state diagram.

[0048] Step 2: Determine the analysis object and object elements

[0049] Based on each interaction scenario between the system and the outside world in the use case diagram in Step 1, select to determine the analysis object; for the determined analysis object, refer to the sequence diagram and state diagram to use the state parameters as the elements of the safety analysis object; the state parameters include messages, state transition conditions, and processing procedures;

[0050] Step 3: Determine the failure analysis rules

[0051] Based on the functional scenario of the analysis object, determine the failure analysis rules for the object elements. The analysis rules include time constraint rules: occurring earlier than the specified time, occurring later than the specified time; sequence constraint rules: occurring before the specified action, occurring after the specified action; state constraint rules: abnormal, missing;

[0052] Step 4: Generate a deviation matrix

[0053] For the characteristics of the equipment software, cross-combine the safety analysis object elements determined in Step 2 and the analysis rules determined in Step 3 to represent the deviation of the design intention, and form a deviation matrix.

[0054] Step 5: Deviation injection model

[0055] Inject each deviation in the deviation matrix formed in Step 4 into the software model established in Step 1. Through the operation of the model and the transition of the state diagram, analyze whether each deviation causes software failure and determine the impact of the failure on the system.

[0056] Step 6: Propose safety requirements or recommended measures

[0057] Based on the various deviations in the deviation matrix and the impact on the system after the deviation injection model, determine the possible causes and consequences of the failure, propose safety requirements or recommended measures, and verify them in the software model established in Step 1.

[0058] Step Seven: Sufficiency Check

[0059] Perform a sufficiency check on the input, output, and processing process of the software to be analyzed, and check whether the security analysis coverage rate reaches 100%.

[0060] Furthermore, the scenarios in Step Two specifically refer to the interaction scenarios between the system and the outside world, which can be expressed by use case diagrams and sequence diagrams. The goal is to perform requirement analysis by extracting system use cases, and then perform system function analysis based on activities, timing, and states. Finally, verify the system logic by running the model. A prototype model can be achieved in the software requirement stage, and observe whether the simulated operation of the software system meets the expectations, so as to further confirm the requirements.

[0061] Furthermore, the messages in Step Two refer to the messages sent and received between objects in the sequence diagram; the state transition conditions refer to the behavioral actions that need to be executed to reach the states specified by the system; the processing process refers to the processing process after the analysis object receives the message and before sending the message; the interfaces between software modules, the messages transmitted, and the state transitions are made explicit through the model.

[0062] Furthermore, the exceptions in Step Three refer to the transmitted information containing error values; the omissions refer to the failure to provide interaction services as required; the redundancies refer to providing services not required. The analysis rules also include other operations that do not meet the design intent; they can be customized according to the software characteristics to expand the application scenarios.

[0063] Furthermore, the characteristics of the equipment software in Step Four refer to the need to select analysis rules suitable for the current analysis software according to the software characteristics and combine them with the analysis objects.

[0064] Furthermore, in Step Four, the security analysis objects determined in Step Two and the analysis rules determined in Step Three are cross-combined to represent the deviations in the running state, forming a deviation matrix. The deviation matrix is the input for software failure analysis.

[0065] Furthermore, the impacts generated by the system in Step Six are divided into catastrophic, severe, medium, and mild; among them, the catastrophic impact means that the key functions of the system where the software is located are lost or the system is damaged; the severe one means that the key functions of the system where the software is located are severely degraded; the medium impact means that the key functions of the system where the software is located are generally degraded and the general functions are lost; the mild impact means that it is lighter than the previous three categories and does not affect the completion of the functions of the system where the software is located.

[0066] Furthermore, the security requirements in Step Six will run through every stage of the software R & D process, and it is necessary to track them in each stage of software design, coding, and verification to ensure that the security of the software meets the system requirements.

[0067] Further, if the safety analysis coverage rate checked in step seven is not up to 100%, then return to step four to check the integrity of the deviation matrix.

[0068] Embodiment: The software failure deviation matrix generation method for aviation equipment provided by the present invention will be illustrated by taking the safety analysis of a certain key subsystem software of aviation equipment as an example.

[0069] The software of a certain system of aviation equipment is one of the core components of an aircraft and is cross-linked with many systems. Figure 2 The software failure deviation matrix generation method for aviation equipment of the present invention is shown, and this method includes the following steps:

[0070] a) For the software requirements and logic control program of a certain key subsystem, eight modules are selected to construct a safety-oriented software system model, and use case diagrams, activity diagrams, sequence diagrams, and state diagrams are generated. Among them, the use case diagram captures the functional requirements of the system by describing the interaction between the system users and the system. The activity diagram describes the workflow of the system within the selected use case scope. The sequence diagram describes the interaction events between the system and external actors over time and the behavior of the system itself. The state diagram describes the complete behavior of the system from the perspective of state transitions.

[0071] b) Based on the model constructed above, according to the scenario content, identify the system state parameters (preconditions, postconditions, system processing procedures) as the elements of the safety analysis object; determine the XX logical safety analysis object, and refer to the system sequence diagram to identify the preconditions, postconditions, and system processing procedures as the object elements of the failure analysis, as shown in Table 1.

[0072] Table 1 Analysis objects of the software model of a certain key subsystem

[0073]

[0074] Table 2 Identification results of control logic object elements

[0075]

[0076] c) According to the characteristics of the selected software, determine the analysis rules as shown in Table 3.

[0077] Table 3 Analysis rules

[0078]

[0079]

[0080] d) Through the determined analysis rules, according to the characteristics of the identified object elements, select the analysis rules for traversal, and comprehensively describe the deviations from the design requirements based on the elements and the traversal results of the analysis rules.

[0081]

[0082] e) Deviation injection model; for the deviation injection system model identified by the above analysis, observe that the deviation may cause danger and conduct safety verification. Simulate the situation where monitoring cannot be performed after XX is started. The model does not detect the XX start signal. At this time, it is impossible to determine whether there is a fault. After a fault, no alarm or switching can be performed, and the XX monitoring control fails.

[0083]

[0084] f) Propose safety requirements or recommended measures; to prevent the aircraft from failing to alarm or switch after a XX fault, it is recommended to periodically monitor the XX start status (control measure).

[0085] g) Sufficiency check: Check that all the analysis objects identified by a certain key subsystem have completed the combined analysis with the analysis rules, and the coverage rate reaches 100%, and end the analysis work.

[0086] In summary, for a certain key subsystem software, a safety-oriented software model construction work has been carried out. Based on the model, safety analysis has been carried out, and corresponding improvement measures have been proposed. The software requirement design is improved with reference to the improvement measures, so as to alleviate the possible safety problems in the system operation from the perspective of software implementation, and ensure that the safety and quality level of a certain safety-critical subsystem software are significantly improved.

[0087] Finally, it should be noted that the above embodiments are only used to illustrate rather than limit the technical solutions of the present invention. Although the present invention has been described in detail with reference to the above embodiments, those of ordinary skill in the art should understand that: the present invention can still be modified or equivalently replaced, and any modification or partial replacement without departing from the spirit and scope of the present invention shall be covered by the scope of the claims of the present invention.

[0088] The above is only a specific embodiment of the present invention, and the present invention is described in detail. The unelaborated parts are conventional technologies. However, the protection scope of the present invention is not limited thereto. Any changes or replacements that can be easily thought of by those skilled in the art within the technical scope disclosed by the present invention should be covered by the protection scope of the present invention. The protection scope of the present invention shall be subject to the protection scope of the claims.

Claims

1. A safety analysis method based on a failure deviation matrix, characterized in that, It includes the following steps: Step 1: Construct a security-oriented software model: According to the software requirement document, conduct requirement analysis to determine the functions of the modeling object, interactive devices, and external interfaces, and construct use case diagrams, activity diagrams, sequence diagrams, and state diagrams; Decompose the requirements to divide the system use cases, and identify the interactive objects related to the use cases to form a use case diagram; for each use case, analyze the activity flow of the use case to form an activity diagram; Combined with the activity diagram, analyze the activity timing, and at the same time define the interaction relationship between the system and external interactive objects to form a sequence diagram; Analyze the running state of the system and draw a system state diagram; Step 2: Determine the analysis object and object elements: Based on each interaction scenario between the system and the outside world in the use case diagram in Step 1, select the analysis object; for the determined analysis object, refer to the sequence diagram and state diagram, and use the state parameters as the elements of the security analysis object; the state parameters include messages, state transition conditions, and processing procedures; Step 3: Determine the failure analysis rules: According to the functional scenarios of the analysis object, determine the failure analysis rules for the object elements. The analysis rules include time constraint rules: occurring earlier than the specified time, occurring later than the specified time; sequence constraint rules: occurring before the specified action, occurring later than the specified action; state constraint rules: message value exception, message missing; Step 4: Generate a deviation matrix: For the characteristics of the equipment software, cross-combine the security analysis object elements determined in Step 2 and the analysis rules determined in Step 3 to represent the deviations of the design intent, and form a deviation matrix; Step 5: Deviation injection model: Inject each deviation in the deviation matrix formed in Step 4 into the software model established in Step 1. Through the operation of the model and the transition of the state diagram, analyze whether each deviation causes software failure and determine the impact of the failure on the system; Step 6: Propose security requirements or recommended measures: According to the various deviations in the deviation matrix and the impact on the system after the deviation injection model, determine the possible causes and consequences of the failure, propose security requirements or recommended measures, and verify them in the software model established in Step 1; Step 7: Sufficiency check: Conduct a sufficiency check on the input, output, and processing procedures of the software to be analyzed, and check whether the security analysis coverage rate reaches 100%; The scenario in Step 2 specifically refers to the interaction scenario between the system and the outside world, which can be expressed by use case diagrams and sequence diagrams; the goal is to extract system use cases, conduct requirement analysis, and then conduct system function analysis based on activities, timing, and states, and finally verify the system logic by running the model; The message in Step 2 refers to the messages sent and received between objects in the sequence diagram; the state transition condition refers to the behavioral actions that need to be executed to reach the specified state of the system; the processing procedure refers to the processing procedure after the analysis object receives the message and before sending the message; The exception in Step 3 refers to the transmitted information containing an error value; the missing means that the interactive service is not provided as required; the redundant means that an unrequested service is provided; the analysis rules also include other operations that do not meet the design intent; it can be customized according to the software characteristics to expand the application scenario; In step 4, the characteristics of the equipment software refer to selecting analysis rules suitable for the current analysis software according to the software characteristics and combining them with the analysis object. In step 4, the safety analysis object determined in step 2 and the analysis rules determined in step 3 are cross-combined to represent the deviation of the operating state, forming a deviation matrix, which is the input for software failure analysis.

2. The safety analysis method based on a failure deviation matrix according to claim 1, characterized in that, In step 6, the impacts generated by the system are divided into catastrophic, severe, medium, and mild. Among them, the catastrophic impact means the loss of key functions of the system where the software is located or the destruction of the system; the severe impact means the serious degradation of the key functions of the system where the software is located; the medium impact means the general degradation of the key functions of the system where the software is located or the loss of general functions; the mild impact means an impact lighter than the previous three categories and does not affect the completion of the functions of the system where the software is located.

3. The safety analysis method based on a failure deviation matrix according to claim 1, characterized in that, In step 6, the safety requirements will run through every stage of the software R & D process, and it is necessary to track them in each stage from software design, coding to verification to ensure that the software security meets the system requirements.

4. The safety analysis method based on a failure deviation matrix according to claim 1, characterized in that, In step 7, if the safety analysis coverage rate is checked and not up to 100%, return to step 4 to check the integrity of the deviation matrix.

Images