Software security analysis method and electronic device

Abstract

The embodiment of the application discloses a software security analysis method and an electronic device. The software security analysis method comprises the following steps: constructing a first business model of a target software system based on a first modeling language; converting the first business model into a second business model of a formal language based on time sequence logic; and performing formal analysis on the second business model, and determining the security state of the target software system according to the analysis result. The application can improve the comprehensiveness, accuracy and effectiveness of the security analysis on the software system.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a software security analysis method and electronic device. Background Technology

[0002] With the popularization and development of cloud computing and internet applications, software functions and structures are becoming increasingly complex, and the security threats faced by systems are also constantly increasing. Threat modeling, as a technique for discovering potential security risks in system architecture during the software design phase, has become an important means of solving software security problems. Currently, commonly used threat modeling methods such as STRIDE, Attack Tree, and threat analysis methods based on CVSS (Common Vulnerability Scoring System) are essentially static analysis methods. They cannot deeply characterize the application context rules specific to software systems, as well as the dynamic behavioral characteristics of their interaction with the environment. Therefore, they are difficult to discover advanced threats strongly correlated with business logic rules in specific environments, and have significant limitations.

[0003] Therefore, there is an urgent need for a low-cost method for applying formal techniques in the analysis of software security defects. Summary of the Invention

[0004] The purpose of this application is to provide a software security analysis method and electronic device to solve the technical problems in related technologies, such as insufficient comprehensiveness, poor accuracy and effectiveness of security analysis of software systems, and high technical threshold and cost for formal analysis of software systems, which makes it difficult to promote in the field of software security.

[0005] To solve the above-mentioned technical problems, the embodiments of this application are implemented as follows: On one hand, embodiments of this application provide a software security analysis method, including: Based on a first modeling language, a first business model of the target software system is constructed; the first business model includes business functional elements and a first security element; the business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is transformed into a second business model based on a formal language of temporal logic; the second business model includes: a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language; The second business model is subjected to formal analysis, and the security status of the target software system is determined based on the analysis results.

[0006] On the other hand, embodiments of this application provide a software security analysis device, including: A construction module is used to construct a first business model of the target software system based on a first modeling language; the first business model includes business functional elements and a first security element; the business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The transformation module is used to transform the first business model into a second business model based on a formal language of temporal logic; the second business model includes: a temporal logic action sequence corresponding to the state transition sequence and a second security element described in the formal language; The analysis module is used to perform formal analysis on the second business model and determine the security status of the target software system based on the analysis results.

[0007] In another aspect, embodiments of this application provide an electronic device, including a processor and a memory electrically connected to the processor, the memory storing a computer program, and the processor being used to call and execute the computer program from the memory to implement the above-described software security analysis method.

[0008] In another aspect, embodiments of this application provide a computer-readable storage medium for storing a computer program that can be executed by a processor to implement the above-described software security analysis method.

[0009] In another aspect, embodiments of this application provide a computer program product, including a computer program, which is executed by a processor to implement the above-described software security analysis method.

[0010] The technical solution of this application embodiment constructs a first business model of the target software system based on a first modeling language. The first business model includes business functional elements and a first security element. The business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is then transformed into a second business model based on a temporal logic formal language. The second business model includes a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language. Formal analysis is then performed on the second business model, and the security state of the target software system is determined based on the analysis results. It is evident that by transforming the first business model into a second business model based on a temporal logic formal language, the business model of the software system can be automatically transformed into a formal model (i.e., the second business model). This allows for formal analysis of the formal model with a unified paradigm, achieving the effect of security analysis of the software system. This not only uncovers deep-seated defects hidden in the software system but also avoids the high cost of manually constructing formal models, significantly reducing the technical threshold for formal verification. Furthermore, since the transformed second business model includes a sequence of temporal logical actions for executing attack use cases, it adds modeling of the behavior of system attackers compared to the traditional business model, and provides a unified paradigm for describing the behavior of system attackers. This helps to complete and standardize the modeling of attacker behavior in software systems, and greatly improves the comprehensiveness, accuracy and effectiveness of security threat and defect analysis for software systems. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in one or more embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in one or more embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a schematic flowchart of a software security analysis method according to some embodiments of this application; Figure 2 This is a schematic diagram of a model class diagram according to some embodiments of this application; Figure 3 This is a schematic diagram of a model use case diagram based on some embodiments of this application; Figure 4 This is a schematic diagram illustrating a security element conversion according to some embodiments of this application; Figure 5 This is a schematic diagram illustrating a security element conversion according to other embodiments of this application; Figure 6 This is a schematic interface diagram of a timing logic action sequence according to some embodiments of this application; Figure 7 This is a schematic interface diagram of an attack chain according to some embodiments of this application; Figure 8 This is a schematic structural diagram of a software security analysis system according to some embodiments of this application; Figure 9 This is a schematic flowchart of a software security analysis method according to some embodiments of this application; Figure 10 This is a schematic block diagram of a software security analysis apparatus according to some embodiments of this application; Figure 11 This is a schematic block diagram of an electronic device according to some embodiments of this application. Detailed Implementation

[0013] This application provides a software security analysis method and an electronic device.

[0014] To enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0015] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. The software security analysis method provided in the embodiments of this application can be executed by an electronic device or by software installed in an electronic device. Specifically, the electronic device can be a terminal device or a server device. The terminal device can include smartphones, laptops, smart wearable devices, in-vehicle terminals, etc., and the server device can include a standalone physical server, a server cluster consisting of multiple servers, or a cloud server capable of cloud computing.

[0016] To address the aforementioned technical problems, industry and academia advocate using formal methods to analyze security vulnerabilities in software systems. Formal verification is a mathematically based analytical technique that employs model checking or theorem proving to rigorously analyze the behavior of a target system, effectively uncovering deeply hidden vulnerabilities. However, due to the high technical barriers and analytical costs associated with formal techniques, their application in the IT industry has been limited, except in a few security-critical fields. Currently, the industry widely uses UML (Unified Modelling Language) for software design modeling and auxiliary analysis. However, UML models are only semi-formal models and cannot be directly used for formal verification. Professional personnel are required to formalize the UML models, resulting in excessively high technical barriers and labor costs for modeling and verification, hindering their widespread adoption in the software security field. Therefore, there is an urgent need for a low-cost method for applying formal techniques in the analysis of software security vulnerabilities. The software security analysis method provided in the embodiments of this application is described in detail below.

[0017] Figure 1 This is a schematic flowchart of a software security analysis method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps S102~S106: Step S102: Based on the first modeling language, construct the first business model of the target software system.

[0018] The first business model includes business function elements and a first security element. The business function elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. In this embodiment, the executor of the business use case is referred to as a business object, and the executor of the attack use case is referred to as a system attacker.

[0019] Optionally, the first modeling language may be UML. The first business model includes the business functional elements of the business object, the business functional elements of the system attacker, and the first security elements.

[0020] In this context, "business objects" refer to legitimate system visitors and system roles, while "system attackers" refer to unauthorized visitors impersonating business objects. The business function elements of a business object include: a first-class diagram, a first-use case diagram, and a first-state diagram. The first-class diagram describes the class attributes of the business object, such as the object class information it belongs to and its component composition. The first-use case diagram describes the business use cases for each object class, i.e., the system functions that each role participates in. The first-state diagram describes the dynamic behavior information of the business object interacting with other parts when executing business use cases; the first-state diagram includes the state transition sequence of the business object executing business use cases.

[0021] The business function elements of a system attacker include: a second type diagram, a second use case diagram, and a second state diagram. The second type diagram includes the class attributes and attack knowledge attributes of the object class being impersonated by the system attacker. The attack knowledge attributes represent the knowledge information required to execute the attack use cases. The second use case diagram includes the system attacker's attack use cases, which represent the dynamic behavior information of the system attacker attacking the target software system; that is, the system attacker executes the business use cases of the impersonated object class based on the knowledge information obtained. The second state diagram describes the dynamic behavior information of the system attacker interacting with other parts when executing attack use cases. The second state diagram includes the state transition sequence for executing attack use cases, that is, the state transition sequence for executing the business use cases of the business object when the system attacker impersonates the business object.

[0022] The first security element includes the first security constraint type and rule description information of the first security constraint rule. Optionally, the first security element may also include information that can uniquely identify the first security constraint rule, such as rule name, rule identifier, rule number, etc. The first security constraint type includes at least one of the following: confidentiality constraint type, integrity constraint type, and availability constraint type. The first security constraint rule of the confidentiality constraint type is used to constrain system attackers from obtaining unauthorized data asset information in the software system; the first security constraint rule of the integrity constraint type is used to indicate the correctness and completeness of data asset information, ensuring that the data has not been modified or damaged without authorization during transmission or storage; the first security constraint rule of the availability constraint type is used to indicate that the business object can ultimately successfully execute the defined business use case.

[0023] Step S104: Transform the first business model into a second business model based on a formal language of temporal logic.

[0024] The second business model includes: a sequence of sequential logical actions corresponding to each state transition sequence, and a second security element described in a formal language. Each state transition sequence refers to a sequence that includes both state transition sequences for executing business use cases and state transition sequences for executing attack use cases.

[0025] Optionally, the formal language based on temporal logic can be TLA+ (Temporal Logic of Actionsplus, enhanced behavioral temporal logic) language. The second security element includes first-order logic rule description information extended with temporal logic. By transforming the first business model into the second business model, the business model of the target software system meets the formal requirements of the formal model, and all descriptive information has a unified paradigm, thus facilitating formal verification of the business model. Furthermore, since the formal model can describe the dynamic behavior of the system, transforming the first business model into the second business model enables the business model to analyze the dynamic behavior of the target software system, thereby verifying the dynamic behavior within the entire system and facilitating the discovery of more comprehensive and deeper system defects.

[0026] Step S106: Perform formal analysis on the second business model and determine the security status of the target software system based on the analysis results.

[0027] The security status of the target software system may include at least one of the following: whether the target software system has security vulnerabilities, system security information, etc. System security information may include at least one of the following: the security level of the target software system, the causes of the security vulnerabilities, etc. The method of representing the system security level is not limited; for example, it can be represented as a security level (such as medium, low, high), security score, etc.

[0028] In the field of software security analysis, formal analysis can include formal verification. Formal verification using a second business model based on a formal language can achieve the goal of verifying whether a target software system has security flaws.

[0029] The technical solution of this application embodiment constructs a first business model of the target software system based on a first modeling language. The first business model includes business functional elements and a first security element. The business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is then transformed into a second business model based on a temporal logic formal language. The second business model includes a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language. Formal analysis is then performed on the second business model, and the security state of the target software system is determined based on the analysis results. It is evident that by transforming the first business model into a second business model based on a temporal logic formal language, the business model of the software system can be automatically transformed into a formal model (i.e., the second business model). This allows for formal analysis of the formal model with a unified paradigm, achieving the effect of security analysis of the software system. This not only uncovers deep-seated defects hidden in the software system but also avoids the high cost of manually constructing formal models, significantly reducing the technical threshold for formal verification. Furthermore, since the transformed second business model includes a sequence of temporal logical actions for executing attack use cases, it adds modeling of the behavior of system attackers compared to the traditional business model, and provides a unified paradigm for describing the behavior of system attackers. This helps to complete and standardize the modeling of attacker behavior in software systems, and greatly improves the comprehensiveness, accuracy and effectiveness of security threat and defect analysis for software systems.

[0030] The following details the construction process of the first business model and the transformation process from the first business model to the second business model.

[0031] In some embodiments, constructing a first business model of the target software system based on a first modeling language can be performed by the following steps A1-A4: Step A1: Construct the business function elements of the business object. The business function elements of the business object include: the first class diagram, the first use case diagram, and the first state diagram.

[0032] The first type of diagram describes the class attributes of business objects, such as the object class information and component composition. The first use case diagram describes the business use cases for each object class, that is, the system functions that each role participates in. Taking a banking system as an example, the business use cases of a legitimate bank user may include logging into the system, querying an account, transferring funds, etc. The first state diagram describes the dynamic behavior information of the business object interacting with other parts when executing business use cases. The first state diagram includes the state transition sequence of the business object executing business use cases.

[0033] The first state diagram includes a sequence of state transitions for business objects executing business use cases. The state transition sequence includes execution constraints and execution action information. Execution action information includes at least one of the following: action type, entry action, internal transition action, and exit action. The action type refers to the type of each action involved in the state transition, which can be represented by the action name. The entry action is the action performed to enter the current state; the exit action is the action performed to exit the current state; and the internal transition action is the action required to complete the current state transition. Optionally, the first state diagram includes the names of each state transition. A state transition can be represented as "name(params)[guards] / actions_list", where "name" represents the name of the state transition, used to uniquely identify it; "params" represents the parameters passed during the state transition; and "guards" represents the conditions that must be met to complete the state transition, i.e., the execution constraints of the state transition. "actions_list" represents the list of actions required to complete the state transition, containing all the internal transition actions required to complete the state transition.

[0034] In this embodiment, the UML model of the target software system, i.e., the first business model, can be created and saved using a commonly used graphical UML model editing tool. The usage of graphical UML model editing tools is a conventional technique and will not be elaborated upon here.

[0035] Step A2: Based on the business function elements of the business object, construct the business function elements of the system attacker. The business function elements of the system attacker include: the second type diagram, the second use case diagram, and the second state diagram.

[0036] The second type of diagram includes the class attributes and attack knowledge attributes of the object class being impersonated by the system attacker. The attack knowledge attributes represent the knowledge information required to execute the attack use case. The second use case diagram includes the system attacker's attack use cases, which represent the dynamic behavior information of the system attacker attacking the target software system, i.e., the business use cases executed by the system attacker on the object class being impersonated. The second state diagram describes the dynamic behavior information of the system attacker interacting with other parts when executing the attack use cases. The second state diagram includes the state transition sequence of the system attacker executing the attack use cases, that is, the state transition sequence of the business use cases executed by the system attacker when impersonating the business object.

[0037] Step A3, construct the first security element; the first security element includes at least one of the following: the first security constraint type and rule description information of the first security constraint rule.

[0038] Optionally, the first safety element may also include information that can uniquely identify the first safety constraint rule, such as rule name, rule identifier, rule number, etc.

[0039] Step A4: Integrate the business function elements and first security elements of the business object and the system attacker to obtain the first business model.

[0040] When integrating the business function elements and first security elements of the business object and the system attacker, the integration process may include the following: integrating the first class diagram of the business object and the second class diagram of the system attacker to obtain the model class diagram of the first business model; integrating the first use case diagram of the business object and the second use case diagram of the system attacker to obtain the model use case diagram of the first business model; integrating the first state diagram of the business object and the second state diagram of the system attacker to obtain the model state diagram of the first business model.

[0041] In this embodiment, when performing step A2, the business function elements of the system attacker can be constructed according to the following steps A21-A23.

[0042] Step A21: For the object class that the system attacker wants to impersonate in the first type of graph, generate a second type of graph of the system attacker corresponding to the object class; the second type of graph includes the system attacker's class attributes and attack knowledge attributes; the attack knowledge attributes are used to represent the knowledge information that needs to be obtained to execute the attack use case.

[0043] In this context, the system attacker corresponding to the object class refers to a system attacker who impersonates a business object belonging to that object class. The second type of diagram for the system attacker includes the attacker's class attributes and attack knowledge attributes; the attacker's class attributes are identical to those of the object class they impersonate. To distinguish between business objects and system attackers, system attacker identification information can be added to the model class diagram to identify the attacker's identity. The model class diagram includes both the first and second types of diagrams. The form of the identification information is not limited; it can be in the form of labels, code comments, etc.

[0044] Step A22: Generate a second use case diagram of the system attacker corresponding to the object class. The second use case diagram includes the system attacker's attack use cases, which are used to represent the dynamic behavior information of the system attacker attacking the target software system.

[0045] For attack use cases of system attackers, templates based on standard attack models (such as the Dolev-Yao attack model) are provided, covering the following paradigms: First, system attackers can be in the same environment as the business objects and have the same system access capabilities.

[0046] Secondly, the attacker does not possess the confidential information held by the business entity, such as passwords and private keys.

[0047] Third, the attacker possesses all publicly available, non-confidential information, such as the public key certificates of business objects.

[0048] Fourth, system attackers can snoop on the interaction messages between business objects and access targets to construct attack payloads.

[0049] Based on the above paradigm, when constructing the second type diagram and second use case diagram of the system attacker, the object class of the already constructed business object can be selected first to quickly construct the system attacker impersonating that object class. The class attributes and methods of the system attacker can automatically inherit the class attributes and methods of the object class it is impersonating. Furthermore, compared to the object class it is impersonating, the system attacker also includes attack knowledge attributes, which represent the knowledge dynamically acquired by the system attacker when executing attack use cases. The difference between the two lies in the initial values ​​of security-related attributes of the system attacker and the object class it is impersonating. For example... Figure 2 As shown, for an electronic banking system, the business object is a legitimate bank user. Both the system attacker and the legitimate bank user class definitions have the attribute "user password". However, in the system attacker's class diagram, the initial value of the attribute "user password" is invalid. Thus, unless the system attacker steals the legitimate bank user's access credentials, the expected result will be failure when executing regular business use cases.

[0050] exist Figure 2 In the diagram, the left side represents the content of the first type of image for a legitimate bank user, while the right side represents the content of the second type of image for a system attacker impersonating that bank user. The attribute "name" represents the account name, and the attribute "Passwd" represents authentication information (such as the user's password). It can be seen that the legitimate bank user's account name and authentication information have corresponding initial values, while the system attacker's account name and authentication information have invalid initial values ​​of "null". The system attacker's second type of image includes the attack knowledge attribute "knowledge".

[0051] After constructing the second type of graph, construct the second use case graph. The second use case graph includes the attack use cases executed by the system attacker when attacking the target software system. Attack use cases can include regular use cases and security extended use cases. Regular use cases are the business use cases of the object class that the system attacker impersonates. Security extended use cases are use cases that are unique to the system attacker relative to the business object, including use cases for obtaining intelligence and constructing attack knowledge.

[0052] Taking the banking system as an example, such as Figure 3As shown, legitimate bank users can execute business use cases (i.e., regular use cases) in the banking system, including logging into the system, querying accounts, and transferring funds. Attackers' attack use cases include regular use cases and security-extended use cases; the attacker's regular use cases are the same as those of legitimate bank users.

[0053] Step A23: Generate a second state diagram based on the second type diagram and the second use case diagram; the second state diagram includes the state transition sequence of the attacker executing the attack use case.

[0054] In this step, the method for generating the second state diagram based on the second type diagram and the second use case diagram is the same as the method for generating the first state diagram based on the first type diagram and the first use case diagram, and will not be described again here. Generating the first state diagram based on the first type diagram and the first use case diagram is a conventional technique (e.g., automatically generating state diagrams using commonly used graphical UML model editing tools), so it will not be described in detail here either.

[0055] Through the above steps A21-A23, the description of the system attacker's class attributes and dynamic behavior is added to the conventional business model, which facilitates the formal verification of the system attacker's dynamic behavior and helps to discover more comprehensive and deeper system defects.

[0056] In some embodiments, the first security constraint type includes at least one of the following: confidentiality constraint type, integrity constraint type, and availability constraint type. When performing step A3 above, i.e., constructing the first security element, it can be performed as follows: For each confidentiality constraint type, a first rule description is generated. This first rule description indicates that a system attacker cannot obtain the confidential business data of the business object. Optionally, the first rule description for the first security constraint rule of the confidentiality constraint type, such as a UML description, can be implemented by adding OCL (Object Constraint Language) rules to the attributes between the attacker's class and the class of the object being impersonated. The paradigm of the first rule description can be: the attacker's knowledge set does not contain elements from the business object's confidential business data set, i.e., the intersection of the two is empty.

[0057] For example, if the attacker's class is B, the knowledge set is the knowledge attribute "knowledge", and the business confidential data set of the business object is the set "Secret", then the following OCL rule expression can be used to indicate that no element in B's knowledge attribute "knowledge" is included in any of the values ​​of the set "Secret": Context B inv:self.knowledge->forAll(e | Secret->excludes(e)). This OCL rule is an invariant constraint, which can be understood as: the business confidential data is not in the hands of the attacker.

[0058] For integrity constraint types, a second rule description is generated. This second rule description indicates that the business data of the business object will not be tampered with by unauthorized users. The first security constraint rule for the integrity constraint type indicates the accuracy and completeness of data asset information, ensuring that the data is not modified or destroyed without authorization during transmission or storage. For example, if object class A has class attributes including `value` and `Hash`, where `value` represents the bill amount and `Hash` represents the hash check value, then the second rule description can be described using the following invariant written in OCL rules: `ContextA inv: self.Hash = HashFunction(self.value)`. The above OCL rule indicates the integrity of the business data of the business object.

[0059] For availability constraint types, a third rule description information, including a sequence logic identifier, is generated. This third rule description information represents the executability of the business object for the business use case in the first use case diagram. The sequence logic identifier represents the sequence logic constraint for successful execution of the business use case. The first security constraint rule for availability constraint types indicates that the business object can ultimately successfully execute the defined business use case. Since availability constraint types involve sequence logic, which cannot be directly described using UML's OCL rules, a sequence logic identifier is introduced. OCL rules incorporating sequence logic identifiers can be called extended OCL rules.

[0060] Optionally, the timing logic identifier includes "◇" and "□", where "◇" means "finally" and "□" means "always". For example, for a TCP (Transmission Control Protocol) server protected by a firewall, the third rule description information of the system availability constraint type can be expressed as follows: a legitimate system visitor will always eventually be able to establish a TCP connection with the target server through the firewall. This can be described first by the following OCL rule: Context Client inv: self.Link = "ESTABLISHED", and then by adding the timing logic identifier "□◇" to the OCL rule, resulting in the following third rule description information, i.e., the extended OCL rule: □◇Context Client inv: self.Link = “ESTABLISHED” The third rule described above states that legitimate visitors will always eventually be able to successfully establish a connection with the target server.

[0061] Table 1 below schematically illustrates the structure of a first security element according to an embodiment of this application. As shown in Table 1, the first security element includes the rule name (e.g., rule1, rule2, etc.), the first security constraint type (e.g., confidentiality constraint type, integrity constraint type, or availability constraint type), and rule description information. The rule name is unique, with C, I, and A representing the confidentiality constraint type, integrity constraint type, and availability constraint type, respectively. The rule description information is the aforementioned OLC rule expression, or an extended OLC rule expression with a temporal logic identifier.

[0062] Table 1

[0063] In the above embodiments, the construction process of the first business model is completed after constructing the business function elements of the business object, the business function elements of the system attacker, and the first security element. Then, the first business model is transformed into a second business model based on a formal language of temporal logic.

[0064] In some embodiments, the first business model is transformed into a second business model based on a formal language of temporal logic, including the following steps B1-B3: Step B1: Extract the model class diagram, model state diagram, and first security element from the first business model; the model class diagram includes the first class diagram and the second class diagram, and the model state diagram includes the first state diagram and the second state diagram.

[0065] Since the business objects and the business function elements and first security elements of the system attacker have been integrated when the first business model is generated, the model class diagram, model state diagram and first security elements need to be extracted first when converting to the second business model, so that the model class diagram, model state diagram and first security elements can be converted separately.

[0066] Step B2: Based on the model class diagram and the model state diagram, generate the timing logic expression, which includes: the initial state predicate expression of the first business model and the timing logic action sequence corresponding to each state transition sequence included in the model state diagram.

[0067] In this context, the temporal logic expression is used to represent the initial state and subsequent actions. Based on this, the temporal logic expression can be a discrete state transition equation composed of the initial state predicate and the corresponding temporal logic action sequence. The temporal logic action sequence can be represented in the form of an expression (or formula).

[0068] Optionally, the sequential logic expression is represented by the following discrete state transition equation: vars□<<var_1,var_2.......,var_n> > Spec□VarInit / \[][Next]_vars In the above equation, “VarInit” is the initial state predicate, “Next” is the sequence expression of the sequential logic action for executing the state transition, and “vars” is a tuple consisting of all sequential logic variables, including sequential logic variables var_1, var_2, ..., var_n.

[0069] Step B3 transforms the first security element into a second security element described in a formal language.

[0070] In this embodiment, when executing step B2, that is, generating the state transition expression corresponding to the first business model based on the model class diagram and the model state diagram, the following steps B21-B24 can be executed: Step B21: Based on the mapping relationship between the class attributes of the object class and the sequential logical variables, convert the class attributes of each object class in the model class diagram into the corresponding first sequential logical variables.

[0071] The mapping relationship between class attributes and sequential logical variables of object classes is predefined and customizable. Different object classes have different sequential logical variables corresponding to their class attributes. For example, if object class A and object class B both have a class attribute x, then the first sequential logical variable corresponding to class attribute x of object class A could be A_x, and the first sequential logical variable corresponding to class attribute x of object class B could be B_x.

[0072] Step B22: Assign values ​​to each first sequential logical variable according to the preset initial values ​​of the class attributes to obtain the initial state predicate of each first sequential logical variable; generate the initial state predicate expression based on the initial state predicate of each first sequential logical variable.

[0073] The initial state predicate expression can be represented in the following form: VarInit□ / \ var_1=… / \ var_2=… / \ var_n=… Step B23: For each state transition sequence in the model state diagram, convert the state transition sequence into a sequence of sequential logic actions.

[0074] The state transition sequence includes execution constraints and execution action information. Execution action information includes at least one of the following: action type, entry action, internal transition action, and exit action. The action type refers to the type of each action involved in the state transition, which can be represented by the action name. The entry action is the action performed to enter the current state; the exit action is the action performed to exit the current state; and the internal transition action is the action required to complete the current state transition. Execution constraints represent the conditions that must be met to complete the state transition.

[0075] Optionally, when converting a state transition sequence into a sequence of sequential logic actions, each state transition can be converted into a sequential logic action described by sequential logic preconditions and postconditions, such as a TLA+ action, and finally merged into a sequence of sequential logic actions. Specifically, the sequential logic preconditions corresponding to the state transition sequence can be determined first based on the execution constraints; the sequential logic postconditions corresponding to the state transition sequence can be determined based on the execution action information; and then the sequence of sequential logic actions can be generated based on the sequential logic preconditions and postconditions. The sequence of sequential logic actions can be represented in the form of expressions (or formulas).

[0076] Taking TLA+ as the formal language as an example, when converting each state transition into a TLA+ action, the state transition name and parameters remain unchanged before and after the conversion. Execution constraints can be used as TLA+ preconditions, and the action type, entry action, internal transition action, and exit action of the state transition sequence can be used as TLA+ postconditions. Furthermore, for attributes whose values ​​are not changed during state transitions, the corresponding TLA+ variables can be described using specific modifiers, such as "UNCHANGED". Attributes whose values ​​are not changed during state transitions refer to variables whose values ​​will not change when the state transition is executed. For example, in banking, when a user queries their balance, the value of the variable "balance" will not change.

[0077] After converting each state transition sequence in the model state diagram into a sequential logic action sequence, it is checked whether any state transition sequences have not been converted. If so, the conversion process continues. If the sequential logic action sequence is represented as an expression, after converting all state transition sequences in the model state diagram into sequential logic action sequence expressions, the sequential logic action sequence expressions corresponding to all state transition sequences are merged to obtain the sequential logic action sequence expression "Next" for the entire business model, which can be represented by the following formula: Next□\ / Action_1\ / Action_2\ / …\ / Action_n Step B24: Integrate the initial state predicate expression and the sequence of temporal logic actions to obtain the temporal logic expression.

[0078] At this point, the construction of the sequential logic expression “Spec□VarInit / \[][Next]_vars” is complete.

[0079] In some embodiments, the second security element includes rule description information based on first-order logic, which is described in a formal language. When transforming the first security element into a second security element described in a formal language, the following steps can be performed: based on the mapping relationship between class attributes of object classes and temporal logic variables, the class attributes of each object class in the rule description information are transformed into corresponding second temporal logic variables, and the description language of the rule description information is transformed from a first modeling language into a formal language, resulting in rule description information based on first-order logic described in a formal language.

[0080] The mapping relationship between class attributes of object classes and sequential logical variables is predefined and customizable. Different object classes correspond to different sequential logical variables for their class attributes.

[0081] This embodiment primarily focuses on converting the first security constraint rules of confidentiality and integrity constraint types. Taking the first business model as a UML model as an example, each first security constraint rule described in UML in the first security element is converted into a second security constraint rule described in TLA+ language.

[0082] For first-level security constraint rules of confidentiality and integrity constraint types, the class attributes of the object classes involved in the OCL rule expression can be converted into corresponding TLA+ variables. The first-order logic propositions in the OCL rule expression can be escaped from OCL language to TLA+ language. The rule name of the OCL rule expression can be directly used as the name of the TLA+ expression, thus generating a TLA+ expression, which is a TLA+ invariant. The escaping from OCL language to TLA+ language is a standard cross-language escaping process and will not be elaborated further.

[0083] Figure 4 This schematically illustrates the principle of converting an OCL rule expression into a TLA+ expression. For example... Figure 4 As shown, the first security constraint rule is named Sec1, and its corresponding first security constraint type is C (i.e., confidentiality constraint type). The OCL rule expression is "Context Attacker inv: self.knowledge->forAll(e | Secret->excludes(e))". This OCL rule expression means that the attacker's knowledge attribute "knowledge" does not contain any elements from the business object's business privacy data set "Secret". This is converted to the corresponding TLA+ expression as follows: Where “Sec1” is the rule name of the TLA+ expression, which is the same as the rule name of the OCL rule expression.

[0084] In some embodiments, the second security element includes: rule description information that extends temporal logic and is described in a formal language. When converting the first security element into a second security element described in a formal language, the method further includes the following step: in response to the rule description information including a temporal logic identifier (such as third rule description information of availability constraint type), concatenating the temporal logic identifier and the rule description information based on first-order logic to obtain rule description information that extends temporal logic.

[0085] This embodiment primarily focuses on converting the first security constraint rule of the availability constraint type. Taking the first business model as a UML model as an example, during the conversion, the temporal logic identifiers (such as "◇" or "□") in the extended OCL rule expression are retained. Then, the OCL rule expression, excluding the temporal logic identifiers, is converted into a first-order logic proposition described in TLA+ language according to the conversion method described in the previous embodiment. Finally, the temporal logic identifiers and the first-order logic proposition described in TLA+ language are concatenated to obtain the TLA+ expression corresponding to the first security constraint rule of the availability constraint type. This TLA+ expression is used to characterize the rule description information extended with temporal logic. The rule name of the extended OCL rule expression can be directly used as the name of the TLA+ expression.

[0086] Figure 5 This schematically illustrates another principle for converting extended OCL rule expressions into TLA+ expressions. For example... Figure 5 As shown, the first security constraint rule is named "AntiDos1", and its corresponding first security constraint type is A (i.e., availability constraint type). The extended OCL rule expression is "□◇Context Client inv: self.Link = "ESTABLISHED"". This extended OCL rule expression means that legitimate visitors (i.e., business objects) will always eventually be able to successfully establish a connection with the target server. This translates to the corresponding TLA+ expression "AntiDos1□□◇Client.Link = "ESTABLISHED", where "AntiDos1" is the rule name of the TLA+ expression, which is the same as the rule name of the OCL rule expression.

[0087] In the above embodiments, by formally transforming all the first security constraint rules in the first business model, the second security element described by TLA+ can be generated.

[0088] Next, the temporal logic action sequences and the second security element corresponding to all the state transition sequences obtained after the transformation are integrated to obtain the second business model. With the temporal logic-based formal language TLA+, the second business model is a TLA+ formal model. The TLA+ formal model can be expressed as the following formula: Spec□VarInit / \[][Next]_vars(1) Spec=>SecPropertySet(2) Formula (1) above represents the discrete state transition equation of the target software system, including the system attacker. Formula (2) represents the theorem description of the security elements of the target software system. The subsequent formal verification process is to determine whether the second business model has security flaws by proving whether formula (2) holds.

[0089] In some embodiments, the security status of the target software system includes whether the target software system has security vulnerabilities. Formal analysis of the second business model, and determination of the security status of the target software system based on the analysis results, can be performed using the following steps: First, execute the sequence of time-sequential logical actions in the second business model.

[0090] The sequence of sequential logical actions to be executed can be any one or more sequential logical action sequences defined in the second business model.

[0091] Secondly, the execution result of the sequential logical action sequence leads to the violation of the second security constraint rule, thus determining that the target software system has a security flaw.

[0092] In some embodiments, the security status of the target software system further includes system security information, which may include at least one of the following: the level of system security and the cause of the security flaw. After determining that a security flaw exists in the target software system, it can first be determined whether there are attack behaviors in the sequence of temporal logical actions that lead to the security flaw. Then, based on the determined attack behaviors and the execution results of the sequence of temporal logical actions that cause the second security constraint rule to be violated, the system security information of the target software system can be analyzed. The method of representing the level of system security is not limited; for example, it can be represented as a security level (such as medium, low, high) or a security score.

[0093] Optionally, the system security level can be determined based on at least one of the following: the second security constraint rule violated by the attack, the number of violated second security constraint rules, the importance of the rules, and the type of security constraint. This information can be obtained through the execution results of a sequence of temporal logical actions. The more second security constraint rules violated by the attack, the more important the rules, and the specific type of the corresponding security constraint, the lower the system security level. Optionally, a pre-defined correspondence between the number of violated second security constraint rules, the importance of the rules, the type of security constraint, and the system security level can be established. Based on this correspondence, the system security level of the target software system can be determined.

[0094] The causes of security deficiencies include violations of second security constraints, i.e., the security deficiencies caused by the violation of which second security constraint(s).

[0095] Optionally, if the second security constraint rule is described in the form of an expression (or formula), then if the expression (or formula) of the second security constraint rule is not true, it is determined that the second security constraint rule has been violated.

[0096] In some embodiments, after formally analyzing the dynamic behavior of the second business model and determining the security status of the target software system based on the analysis results, the following steps C1-C2 are further included: Step C1: In response to the determination that a security flaw exists in the target software system, a second security flaw information based on a formal language is generated.

[0097] The second security flaw information includes at least one of the following: the second security constraint rule based on a formal language violated by the attack behavior that caused the security flaw, the type of the second security constraint, and the sequence of temporal logical actions corresponding to the attack behavior. The sequence of temporal logical actions that violates the second security constraint rule of the second business model is the attack behavior that caused the security flaw, and the context of the attack behavior includes all actions in the sequence of temporal logical actions.

[0098] Step C2: Based on the first business model, perform attribution analysis on the second security defect information to obtain the first security defect information based on the first modeling language.

[0099] Attribution analysis is essentially a process of transforming security flaw information into its formal form. The first security flaw information includes at least one of the following: the first security constraint rule violated by the attack that caused the security flaw, the type of the first security constraint, and the attack chain corresponding to the attack. The attack chain corresponding to the attack represents all system state transition steps experienced by the attacker from system startup until the attack target is achieved.

[0100] Optionally, step C2 can be performed as the following steps C21-C23: Step C21: Based on the transformation relationship between the first security constraint rule and the second security constraint rule, transform the second security constraint rule corresponding to the attack behavior into the first security constraint rule.

[0101] Since the first security constraint rule and the second security constraint rule have the same rule name, there is a one-to-one correspondence between the first security constraint rule and the second security constraint rule. Based on this correspondence, the second security constraint rule can be accurately converted into the corresponding first security constraint rule.

[0102] Step C22: Based on the conversion relationship between the first security constraint type and the second security constraint type, convert the second security constraint type corresponding to the attack behavior into the first security constraint type.

[0103] The first security constraint type and the second security constraint type are the same.

[0104] Step C23: Transform the sequence of temporal logic actions corresponding to the attack behavior into a state transition sequence, and transform each temporal logic variable in the sequence of temporal logic actions into a class attribute of the object class to obtain the attack chain.

[0105] When converting the sequence of sequential logical actions corresponding to an attack that leads to a security flaw into an attack chain, each action in the sequence of sequential logical actions is first converted into a state transition defined in the model state diagram of the first business model. Then, the values ​​of the sequential logical variables corresponding to each action in the sequence of sequential logical actions are converted into class attribute values ​​of the object class defined in the model class diagram of the first business model. Since the state transitions defined in the model state diagram and the corresponding action names (i.e., action types) in the sequence of sequential logical actions are the same, there is also a one-to-one correspondence between the sequential logical variables and the class attributes of the object class. Based on this correspondence, the value of each sequential logical variable can be accurately converted into the value of the class attribute of the object class.

[0106] Figure 6 This illustration schematically demonstrates the interface effect of a sequential logic action sequence. Figure 7 The illustration shows the interface effect of the attack chain obtained after converting the sequence of temporal logic actions. For example... Figure 6 As shown, in the first n rows of the interface, each element represents a TLA+ action, i.e., a state transition, including TLA+ action 1, TLA+ action 2, ..., and TLA+ action n. The sequence of the first n rows of TLA+ actions corresponds to the TLA+ action sequence from state 1 (as shown in "State{num=1}" on the interface) to state n (as shown in "State{num=n}" on the interface). Starting from the (n+1)th row of the interface, the details of "TLA+ action n" are displayed. Optionally, clicking the display symbol "●" in front of a "TLA+ action" will open the details corresponding to that "TLA+ action". Clicking the display symbol "●" in front of the "TLA+ action" again will hide the expanded details again.

[0107] Figure 6The interface shown exemplifies the details of "TLA+ Action n". The details of "TLA+ Action n" include the values ​​of various TLA+ variables in the target software system after executing TLA+ Action n. For example, after executing TLA+ Action n, the value of the TLA+ variable "AclRuleSet" is "{}". In actual execution, if it is determined that the execution of a certain TLA+ action causes a change in the value of the corresponding TLA+ variable, prompts can be provided for that TLA+ action and its corresponding TLA+ variable, such as rendering or marking the value of the TLA+ variable. Of course, Figure 6 The content displayed on the interface is only an example. In actual execution, you can select any line of TLA+ actions to scale the display.

[0108] Suppose that after executing a certain TLA+ action sequence, the change in the value of the TLA+ variable "FwDataChannel" causes a violation of the security constraint rules specified by the TLA+ formal model, then the TLA+ action sequence is recorded, and the corresponding attack chain is generated. The attack chain is as follows: Figure 7 As shown. In Figure 7 In the attack chain, following the state transition order, the attack chain includes the states UsrCommotSpaAuth, UsrConnectSvr, ..., AttackerRcvSynAck. Optionally, for each state, the class attribute values ​​of the corresponding system object classes can also be displayed. Here, the object classes refer to the various object classes in the system involved in the attack, including the attacker.

[0109] In this embodiment, model checking, i.e., exhaustively enumerating the system state space, can be used to simulate the dynamic behavior of the target software system, thereby verifying whether the defined security constraint rules are valid. For dynamic behaviors that violate security constraint rules, i.e., attack behaviors that lead to security vulnerabilities, the corresponding temporal logic action sequence can be recorded. This temporal logic action sequence is described in a formal language based on temporal logic. Then, by converting the temporal logic action sequence into an attack chain described in a first modeling language, which is a commonly used modeling language in software system design and is easier for users to understand, restoring the formal language to the first modeling language makes the final security vulnerability information easier for users to understand.

[0110] The following example uses UML as the primary modeling language and TLA+ as the formal language to illustrate the detailed execution process of software security analysis.

[0111] Figure 8 This is a schematic structural diagram of a software security analysis system according to an embodiment of this application. Figure 8As shown, the software security analysis system includes an enhanced UML model generation subsystem, a formal model generation subsystem, and a security analysis subsystem. The enhanced UML model generation subsystem generates an enhanced UML model (i.e., the first business model), the formal model generation subsystem converts the enhanced UML model into a TLA+ formal model, and the security analysis subsystem performs security analysis based on the TLA+ formal model to verify whether the target software system has security vulnerabilities and presents the security analysis results to the user.

[0112] The enhanced UML model generation subsystem includes a user interface, a module for constructing the first business function elements of the business object, a module for constructing the second business function elements of the system attacker, a security element construction module, and an enhanced UML model generation module. The user interface provides an interactive interface for users, who can be technical personnel performing security analysis of the target software system. The first business function element construction module constructs the business function elements of the business object; the second business function element construction module constructs the business function elements of the system attacker; the security element construction module constructs the first security element; and the enhanced UML model generation module integrates the business function elements of the business object, the business function elements of the system attacker, and the first security element to generate an enhanced UML model.

[0113] The formal model generation subsystem includes a model preprocessing module, a TLA+ subject generation module, a security element generation module, and a TLA+ rule generation module. The model preprocessing module extracts the model class diagram, model state diagram, and first security element from the enhanced UML model. The model class diagram includes a first-class diagram of business objects and a second-class diagram of system attackers. The model state diagram includes a first-state diagram of business objects and a second-state diagram of system attackers. The first security element includes the first security constraint type and rule description information of the first security constraint rule. Optionally, the first security element may also include information that uniquely identifies the first security constraint rule, such as rule name, rule identifier, and rule number. The model preprocessing module transmits the extracted model class diagram and model state diagram to the TLA+ subject generation module, and transmits the extracted first security element to the security element generation module. The TLA+ subject generation module generates TLA+ expressions in the TLA+ formal model based on the model class diagram and model state diagram. These TLA+ expressions include initial state predicate expressions and TLA+ action sequences corresponding to each state transition sequence. The security element generation module transforms the first security element into a second security element described in the TLA+ language. The TLA+ rule generation module integrates the temporal logic expression output by the TLA+ main generation module and the second security element output by the security element generation module to obtain a complete TLA+ formal model.

[0114] The security analysis subsystem includes a formal verification module and an attribution analysis module. The formal verification module reads the TLA+ formal model and verifies the validity of the defined security constraints by simulating the dynamic behavior of the target software system through model checking, i.e., exhaustively enumerating the system's state space. If security constraints are found in the TLA+ formal model, second security flaw information based on the TLA+ language is generated. This second security flaw information may include at least one of the following: the second security constraint rule violated by the attack behavior leading to the security flaw, the type of the second security constraint, and the corresponding TLA+ action sequence. For dynamic behaviors that violate security constraints (i.e., attacks leading to security flaws), the formal verification module records the corresponding TLA+ action sequence, which is described using the TLA+ language. The attribution analysis module combines information from the enhanced UML model to perform attribution analysis on the second security flaw information, obtaining first security flaw information based on UML. The attribution analysis module reads each attack behavior that leads to a security flaw, i.e., the TLA+ action sequence that violates the security constraints rules specified in the TLA+ formal model. Then, it combines the information in the enhanced UML model to perform attribution analysis on each attack behavior that leads to a security flaw, reconstructs the context and steps of the threat, and outputs the attack chain.

[0115] based on Figure 8 The software security analysis system shown herein can be used by users who are engaged in the development and design of software systems and wish to identify security risks or conduct security assessments on existing software systems and wish to uncover security vulnerabilities introduced by design logic. They can use the software security analysis method provided in this application to verify the security vulnerabilities of the software system.

[0116] First, construct an enhanced UML model of the target software system. The process of constructing the enhanced UML model is as follows: Figure 9 As shown, the process includes the following steps S901-S904: Step S901: Construct the business function elements of the business object.

[0117] Step S902: Construct the business function elements of the system attacker.

[0118] Step S903: Construct the first security element, which includes: the rule name of the first security constraint rule, the type of the first security constraint, and the rule description information.

[0119] Step S904: Integrate the business function elements of the business object, the business function elements of the system attacker, and the first security element to obtain the enhanced UML model.

[0120] During step S901, the user interacts with the first business function element construction module through the user interface of the software security analysis system. By editing the UML view, a standard UML model of the target software system is created. This standard UML model describes the normal functional behavior of the system, excluding system attackers, and includes a first class diagram, a first use case diagram, and a first state diagram of business objects. The first class diagram identifies the roles involved in system functions by refining use case scenarios and defines object classes containing static and dynamic attributes. The first use case diagram includes standard business use cases defined according to the business requirement specifications. The first state diagram refines the standard business use cases described in the first use case diagram. Combining the object class roles, interoperability, and business logic involved in the business use cases, a state view of the participating roles is constructed. This state view includes action types, entry actions, internal transition actions, and exit actions.

[0121] During step S902, the user interacts with the second business function element construction module through the user interface of the software security analysis system. This module adds business function elements representing the system attacker to the standard UML model. Optionally, the user can construct these elements in two ways. One is through manual modeling, adding a system attacker class role to the standard UML model and manually adding and defining the system attacker's use case diagrams and class diagrams. The other is through Dolev-Yao paradigm modeling, where the user selects the object class of the business object defined in the standard UML model as the object the system attacker intends to impersonate through the second business function element construction module.

[0122] The second business function element construction module automatically generates the system attacker's class definition based on the class definition of the object class to be imitated. The system attacker's class attributes completely inherit the class attributes of the object class being imitated, and an additional "knowledge" attribute is added to represent the knowledge information the system attacker needs to acquire to attack the target software system. The second business function element construction module automatically generates the system attacker's use case diagram based on the use case definition of the object class to be imitated. The system attacker's use case diagram includes the system attacker's attack use cases, which represent the dynamic behavior information of the system attacker attacking the target software system, i.e., the system attacker executing the business use cases of the object class being imitated. Attack use cases include regular use cases and security extended use cases. Regular use cases are the business use cases of the object class being imitated by the system attacker. Security extended use cases are use cases unique to the system attacker relative to the business object, including intelligence gathering and attack knowledge construction use cases, representing the system attacker's preparatory work and preliminary actions to attack the target software system. Subsequently, the second business function element construction module, based on the aforementioned steps, refines and improves the behavioral description of the system attacker, including adjusting the initial values ​​in the class attributes of the system attacker, adjusting and refining attack use cases, and automatically constructing the state diagram of the system attacker.

[0123] During step S903, the user interacts with the security element construction module through the user interface of the software security analysis system. The security element construction module creates the security elements that the target software system is expected to follow. Each security element includes multiple security constraint rules, and specific information may include the rule name, constraint type, and description. Rule names are unique.

[0124] The business function elements of the business object constructed by the first business function element construction module, the business function elements of the system attacker constructed by the second business function element construction module, and the security elements constructed by the security element construction module are all output to the enhanced UML model generation module. The enhanced UML model is obtained by integrating the various information.

[0125] Secondly, the enhanced UML model of the target software system is converted into a TLA+ formal model.

[0126] The model preprocessing module extracts the model class diagram, model state diagram, and first safety element from the enhanced UML model, transmits the model class diagram and model state diagram to the TLA+ main body generation module, and transmits the first safety element to the safety element generation module.

[0127] The TLA+ main generation module formally transforms the model class diagram, generating TLA+ variable tuples and initial state predicates described in the TLA+ language. The TLA+ variable tuple consists of multiple TLA+ variables, which can be obtained by mapping each object class's class attribute to a corresponding TLA+ variable, and then merging all TLA+ variables. The TLA+ variable tuple can be represented in the following form: vars□<<var_1,var_2.......,var_n> The initial state predicate can be obtained by obtaining the initial values ​​of the class attributes of the object class one by one and assigning the initial values ​​to the corresponding TLA+ variables in the TLA+ variable tuple. The initial state predicate expression can be represented in the following form: VarInit□ / \var_1=… / \var_2=… / \var_n=…. The TLA+ main body generation module formally transforms the model state diagram. Specifically, it transforms each state transition in the model state diagram into a corresponding TLA+ action, while keeping the action name and parameters unchanged. It also transforms the constraints that the state transition must satisfy into preconditions for the TLA+ actions, and the action list, entry action, internal transition action, and exit action of the state transition into postconditions for the TLA+ actions.

[0128] For example, a UML state diagram of a bank user's basic business includes state transition sequences for deposit, withdrawal, and transfer operations, involving parameters such as customers, the entire set of bank users, and transfer amounts. Taking the withdrawal operation's state transition as an example, the constituent elements of this state transition include the following: Prerequisites: [<cstm,acnt> ∈has_account,acnt.balance>=amt] State transition name: Withdraw(cstm,acnt,amt) Transfer action: do / acnt'.balance = acnt.balance - amt The components of the above state transition are respectively converted into corresponding TLA+ action elements: TLA+ prerequisites: / \<cstm,acnt> ∈has_account / \ acnt.balance>=amt TLA + Action Name: Withdraw(cstm,acnt,amt) TLA+ postcondition: 'acnt'.balance = acnt.balance-amt UNCHANGED <cstm> By combining the above TLA+ action elements, we can obtain the following complete TLA+ action expression: Withdraw(cstm,acnt,amt) == / \<cstm,acnt> ∈has_account / \ acnt.balance>=amt / \ Acnt'.balance = acnt.balance-amt UNCHANGED <cstm> Here, " / \" represents a conjunction operation, meaning that if the action is enabled, all preceding and following conditions must be met. It can be seen that the value of the attribute cstm (username) remains unchanged before and after the transformation. Therefore, in the transformed TLA+ action expression, the modifier "UNCHANGED" indicates that the corresponding variable has not changed in the postconditions.

[0129] After converting all state transitions in the enhanced UML model into TLA+ action expressions, all TLA+ action expressions are merged into a TLA+ action sequence for the entire business model of the target software system, which can be represented as follows: Next□\ / Action_1\ / Action_2\ / …\ / Action_n. Here, "\ / " represents a disjunction operation, meaning that if any TLA+ action is enabled, it will drive a change in the subsequent state.

[0130] By integrating the initial state predicate expression and the TLA+ action sequence, a TLA+ expression describing the behavior of the entire system is obtained.

[0131] The security element generation module transforms each security constraint rule into a security constraint rule described in the TLA+ language. The TLA+ rule generation module merges the TLA+ expressions output by the TLA+ main generation module and the security constraint rules output by the security element generation module to obtain a complete TLA+ formal model.

[0132] Optionally, after the TLA+ formal model is built, users can adjust the TLA+ formal model as needed, such as adding custom security constraint rules directly using the TLA+ language.

[0133] Afterwards, users can choose to initiate formal verification, which verifies whether the target software system has security flaws through the formal verification module, and then uses the attribution analysis module to perform attribution analysis on the security flaw information in combination with the information in the enhanced UML model, thus obtaining UML-based security flaw information.

[0134] The formal verification module reads the TLA+ formal model, initiates the formal verification process, and simulates the dynamic behavior of the target software system through model checking, i.e., exhaustively enumerating the system state space, to check for any dynamic behaviors that violate security constraint rules. For the verified attack behaviors that lead to security defects, the module generates corresponding second security defect information, including the rule name of the violated TLA+ security constraint rule (i.e., the security constraint rule in the TLA+ formal model), the type of security constraint, and the TLA+ action sequence from the initial state to the state of rule violation.

[0135] The attribution analysis module reads the second security flaw information. If the number of rule violations is 0, an analysis report with no security flaws can be directly generated. If the number of records is not 0, an attribution analysis is performed on each second security flaw information using an enhanced UML model to transform the formalized second security flaw information into an attack chain expressed in UML. Then, an analysis report is generated based on the results of the attribution analysis and presented to the user. In the analysis report, each security flaw information may include: the violated UML security constraint rule (i.e., the security constraint rule in the UML model) and the attack chain composed of UML state transition sequences.

[0136] As can be seen, the software security analysis method provided in this embodiment transforms the first business model into a second business model based on a temporal logic formal language. This allows the software system's business model to be automatically converted into a formal model (i.e., the second business model), enabling formal analysis of the formal model with a unified paradigm. This achieves the effect of security analysis of the software system, not only uncovering deep-seated defects hidden in the software system but also avoiding the high costs associated with manual formal modeling by users, significantly lowering the technical threshold for formal verification. Furthermore, since the transformed second business model includes a sequence of temporal logic actions, including the execution of business use cases by a system attacker, it adds modeling of the attacker's behavior compared to traditional business models and provides a unified paradigm for describing the attacker's behavior. This facilitates complete and standardized modeling of attacker behavior in software systems, greatly improving the comprehensiveness, accuracy, and effectiveness of security threat and defect analysis for software systems.

[0137] In summary, specific embodiments of this subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing can be advantageous.

[0138] The above are the software security analysis methods provided in the embodiments of this application. Based on the same idea, the embodiments of this application also provide a software security analysis device.

[0139] Figure 10 This is a schematic block diagram of a software security analysis apparatus according to an embodiment of this application, such as... Figure 10 As shown, the device includes: Module 101 is used to construct a first business model of the target software system based on a first modeling language; the first business model includes business function elements and a first security element; the business function elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases; The conversion module 102 is used to convert the first business model into a second business model based on a formal language of temporal logic; the second business model includes: a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language; Analysis module 103 is used to perform formal analysis on the second business model and determine the security status of the target software system based on the analysis results.

[0140] The technical solution of this application embodiment constructs a first business model of the target software system based on a first modeling language. The first business model includes business functional elements and a first security element. The business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is then transformed into a second business model based on a temporal logic formal language. The second business model includes a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language. Formal analysis is then performed on the second business model, and the security state of the target software system is determined based on the analysis results. It is evident that by transforming the first business model into a second business model based on a temporal logic formal language, the business model of the software system can be automatically transformed into a formal model (i.e., the second business model). This allows for formal analysis of the formal model with a unified paradigm, achieving the effect of security analysis of the software system. This not only uncovers deep-seated defects hidden in the software system but also avoids the high cost of manually constructing formal models, significantly reducing the technical threshold for formal verification. Furthermore, since the transformed second business model includes a sequence of temporal logical actions for executing attack use cases, it adds modeling of the behavior of system attackers compared to the traditional business model, and provides a unified paradigm for describing the behavior of system attackers. This helps to complete and standardize the modeling of attacker behavior in software systems, and greatly improves the comprehensiveness, accuracy and effectiveness of security threat and defect analysis for software systems.

[0141] Those skilled in the art will understand that Figure 10 The software security analysis device described above can be used to implement the software security analysis method described above. The detailed description should be similar to that in the method section above. To avoid being too cumbersome, it will not be repeated here.

[0142] Following the same line of thought, embodiments of this application also provide an electronic device, such as... Figure 11 As shown. Electronic devices can vary considerably due to differences in configuration or performance, and may include one or more processors 1101 and memory 1102. Memory 1102 may store one or more application programs or data. Memory 1102 may be temporary or persistent storage. The application programs stored in memory 1102 may include one or more modules (not shown), each module may include a series of computer-executable instructions for the electronic device. Furthermore, processor 1101 may be configured to communicate with memory 1102 and execute the series of computer-executable instructions in memory 1102 on the electronic device. The electronic device may also include one or more power supplies 1103, one or more wired or wireless network interfaces 1104, one or more input / output interfaces 1105, and one or more keyboards 1106.

[0143] Specifically, in this embodiment, the electronic device includes a memory and one or more programs, wherein one or more programs are stored in the memory, and one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for use in the electronic device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following: Based on a first modeling language, a first business model of the target software system is constructed; the first business model includes business functional elements and a first security element; the business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is transformed into a second business model based on a formal language of temporal logic; the second business model includes: a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language; The second business model is subjected to formal analysis, and the security status of the target software system is determined based on the analysis results.

[0144] The technical solution of this application embodiment constructs a first business model of the target software system based on a first modeling language. The first business model includes business functional elements and a first security element. The business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is then transformed into a second business model based on a temporal logic formal language. The second business model includes a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language. Formal analysis is then performed on the second business model, and the security state of the target software system is determined based on the analysis results. It is evident that by transforming the first business model into a second business model based on a temporal logic formal language, the business model of the software system can be automatically transformed into a formal model (i.e., the second business model). This allows for formal analysis of the formal model with a unified paradigm, achieving the effect of security analysis of the software system. This not only uncovers deep-seated defects hidden in the software system but also avoids the high cost of manually constructing formal models, significantly reducing the technical threshold for formal verification. Furthermore, since the transformed second business model includes a sequence of temporal logical actions for executing attack use cases, it adds modeling of the behavior of system attackers compared to the traditional business model, and provides a unified paradigm for describing the behavior of system attackers. This helps to complete and standardize the modeling of attacker behavior in software systems, and greatly improves the comprehensiveness, accuracy and effectiveness of security threat and defect analysis for software systems.

[0145] This application also proposes a computer-readable storage medium that stores one or more computer programs, each including instructions that, when executed by an electronic device including multiple applications, enable the electronic device to perform various processes of the above-described software security analysis method embodiments, specifically for executing: Based on a first modeling language, a first business model of the target software system is constructed; the first business model includes business functional elements and a first security element; the business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is transformed into a second business model based on a formal language of temporal logic; the second business model includes: a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language; The second business model is subjected to formal analysis, and the security status of the target software system is determined based on the analysis results.

[0146] The technical solution of this application embodiment constructs a first business model of the target software system based on a first modeling language. The first business model includes business functional elements and a first security element. The business functional elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases. The first business model is then transformed into a second business model based on a temporal logic formal language. The second business model includes a temporal logic action sequence corresponding to each state transition sequence and a second security element described in the formal language. Formal analysis is then performed on the second business model, and the security state of the target software system is determined based on the analysis results. It is evident that by transforming the first business model into a second business model based on a temporal logic formal language, the business model of the software system can be automatically transformed into a formal model (i.e., the second business model). This allows for formal analysis of the formal model with a unified paradigm, achieving the effect of security analysis of the software system. This not only uncovers deep-seated defects hidden in the software system but also avoids the high cost of manually constructing formal models, significantly reducing the technical threshold for formal verification. Furthermore, since the transformed second business model includes a sequence of temporal logical actions for executing attack use cases, it adds modeling of the behavior of system attackers compared to the traditional business model, and provides a unified paradigm for describing the behavior of system attackers. This helps to complete and standardize the modeling of attacker behavior in software systems, and greatly improves the comprehensiveness, accuracy and effectiveness of security threat and defect analysis for software systems.

[0147] This application provides a computer program product, including a computer program, which is executed by a processor to implement the various processes of the above-described software security analysis method embodiments and achieve the same technical effects. To avoid repetition, it will not be described again here.

[0148] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0149] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0150] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0151] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0152] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0153] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0154] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0155] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0156] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0157] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0158] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0159] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0160] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the scope of the claims of this application.< / cstm> < / cstm>

Claims

1. A software security analysis method, comprising: Based on the first modeling language, construct the first business model of the target software system; The first business model includes business function elements and a first security element; The business function elements include state transition sequences for executing business use cases and state transition sequences for executing attack use cases; The first business model is transformed into a second business model based on a formal language of temporal logic; The second business model includes: a sequence of temporal logical actions corresponding to each state transition sequence and a second security element described in the formal language; The second business model is subjected to formal analysis, and the security status of the target software system is determined based on the analysis results.

2. The method according to claim 1, wherein constructing the first business model of the target software system based on the first modeling language comprises: Construct the business functional elements of a business object; The business function elements of the business object include: a first class diagram, a first use case diagram, and a first state diagram; Based on the business function elements of the business object, the business function elements of the system attacker are constructed; the business function elements of the system attacker include: a second type diagram, a second use case diagram, and a second state diagram. Construct the first security element; the first security element includes the first security constraint type and rule description information of the first security constraint rule; The first business model is obtained by integrating the business object, the business function elements of the system attacker, and the first security element.

3. The method according to claim 2, wherein constructing the business function elements of a system attacker based on the business function elements of the business object includes: For the object class that the system attacker wants to impersonate in the first type of graph, a second type of graph of the system attacker is generated; the second type of graph includes the class attribute and attack knowledge attribute of the system attacker; the attack knowledge attribute is used to represent the knowledge information required to execute the attack use case; Generate a second use case diagram of the attacker in the system; the second use case diagram includes the attack use cases. Based on the second class diagram and the second use case diagram, a second state diagram is generated; the second state diagram includes a state transition sequence for executing the attack use case.

4. The method according to claim 2, wherein the first security constraint type includes at least one of the following: confidentiality constraint type, integrity constraint type, and availability constraint type; The construction of the first security element includes: For the aforementioned confidentiality constraint type, generate first rule description information; The first rule description information is used to indicate that the system attacker cannot obtain the business confidential data of the business object; For the integrity constraint type, a second rule description is generated; the second rule description is used to indicate that the business data of the business object is not modified by unauthorized users; For the availability constraint type, a third rule description information including a timing logic identifier is generated; the third rule description information is used to represent the executability of the business object for the business use case in the first use case diagram; the timing logic identifier is used to represent the timing logic constraint for successfully executing the business use case.

5. The method according to claim 2, wherein converting the first business model into a second business model based on a formal language of temporal logic comprises: Extract the model class diagram, model state diagram, and the first security element from the first business model; The model class diagram includes the first class diagram and the second class diagram, and the model state diagram includes the first state diagram and the second state diagram; Based on the model class diagram and the model state diagram, generate a timing logic expression; The temporal logic expression includes: the initial state predicate expression of the first business model, and the temporal logic action sequence corresponding to each state transition sequence included in the model state diagram; The first security element is transformed into a second security element described in the formal language.

6. The method according to claim 5, wherein generating a timing logic expression based on the model class diagram and the model state diagram comprises: Based on the mapping relationship between the class attributes of object classes and sequential logical variables, the class attributes of each object class in the model class diagram are transformed into the corresponding first sequential logical variables; Based on the preset initial values ​​of the class attributes, each first time-series logical variable is assigned a value to obtain the initial state predicate of each first time-series logical variable; based on the initial state predicate of each first time-series logical variable, the initial state predicate expression is generated. For each state transition sequence in the model state diagram, the state transition sequence is transformed into a sequence of temporal logic actions; The initial state predicate expression and the sequence of temporal logic actions are integrated to obtain the temporal logic expression.

7. The method according to claim 6, wherein the state transition sequence comprises: Execution constraints and execution action information; the execution action information includes at least one of the following: action type, entry action, internal conversion action, and exit action; The step of converting the state transition sequence into a temporal logic action sequence includes: Based on the execution constraints, determine the sequential logic preconditions corresponding to the state transition sequence; Based on the execution action information, determine the timing logic postconditions corresponding to the state transition sequence; The timing logic action sequence is generated based on the timing logic preconditions and the timing logic postconditions.

8. The method according to claim 5, wherein the second security element includes rule description information based on first-order logic; The step of converting the first security element into a second security element described in a formal language includes: Based on the mapping relationship between the class attributes of object classes and the temporal logic variables, the class attributes of each object class in the rule description information are transformed into corresponding second temporal logic variables, and the description language of the rule description information is transformed from the first modeling language into the formal language to obtain the rule description information based on first-order logic.

9. The method according to claim 8, wherein the second security element further comprises: It expands the rule description information of sequential logic; The step of converting the first security element into a second security element described in the formal language further includes: In response to the rule description information including a temporal logic identifier, the temporal logic identifier and the rule description information based on first-order logic are concatenated to obtain the rule description information extended with temporal logic.

10. The method according to claim 5, wherein the second security element includes a second security constraint rule; the security state includes: Does the target software system have security flaws? The formal analysis of the second business model, and the determination of the security status of the target software system based on the analysis results, includes: Execute the sequence of time-series logical actions in the second business model; In response to the execution result of the sequential logic action sequence causing the second security constraint rule to be violated, it is determined that the target software system has a security flaw.

11. The method according to claim 10, wherein the security state further includes: System security information; The system security information includes at least one of the following: the system security level, and the cause of the security flaw; After determining that the target software system has a security flaw, the process further includes: It was determined that an attack behavior leading to a security flaw existed in the sequence of time-series logical actions; Based on the attack behavior and the execution results, analyze the system security information of the target software system.

12. The method according to claim 10, further comprising, after performing formal analysis on the second business model and determining the security status of the target software system based on the analysis results: In response to determining that the target software system has a security flaw, a second security flaw information based on the formal language is generated; The second security flaw information includes at least one of the following: the second security constraint rule based on the formal language violated by the attack behavior, the second security constraint type, and the sequence of temporal logic actions corresponding to the attack behavior; Based on the first business model, the second security defect information is subjected to attribution analysis to obtain the first security defect information based on the first modeling language; The first security flaw information includes at least one of the following: the first security constraint rule violated by the attack behavior, the first security constraint type, and the attack chain corresponding to the attack behavior.

13. The method according to claim 12, wherein the attribution analysis of the second security defect information based on the first business model to obtain the first security defect information based on the first modeling language includes at least one of the following: Based on the transformation relationship between the first security constraint rule and the second security constraint rule, the second security constraint rule corresponding to the attack behavior is transformed into the first security constraint rule; Based on the conversion relationship between the first security constraint type and the second security constraint type, the second security constraint type corresponding to the attack behavior is converted into the first security constraint type; The attack chain is obtained by converting the sequence of temporal logic actions into the state transition sequence and converting each temporal logic variable in the sequence of temporal logic actions into a class attribute of an object class.

14. An electronic device comprising a processor and a memory electrically connected to the processor, the memory storing a computer program, the processor being configured to call and execute the computer program from the memory to implement the software security analysis method as claimed in any one of claims 1-13.

15. A computer program product comprising a computer program that is executed by a processor to implement the software security analysis method as described in any one of claims 1-13.

Images