A social engineering attack automatic detection method based on multi-view subject modeling

Abstract

The application discloses a kind of social engineering attack automatic detection method based on multi-view subject modeling, contain following steps: step (1) scene modeling step: enterprise provides the relevant document needed for modeling, according to document, model scene, including organization setting, business target, social interaction and four dimensions of human characteristics, generate scene fact, when modeling is completed, execute step (2).Step (2) threat reasoning step: existing social engineering attack detection method relies on dialogue or text, cannot detect the security threat existing in complex system.Therefore, threat reasoning rule based on logic reasoning is used to reason the threat of scene, and the automatic reasoning of scene threat is realized by logic programming language prolog.The scene modeling suitable for large-scale complex system and the automatic detection of threat in scene.

Description

Technical Field

[0001] This invention relates to the field of social engineering attack defense, and in particular to an automatic detection method for social engineering attacks based on multi-perspective agent modeling, which is applicable to scene modeling of large-scale complex systems and automatic detection of threats in the scene. Background Technology

[0002] Considering security factors during the requirements phase of system development is widely recognized as an effective way to reduce the overall security cost of a system. Empirical studies have verified that the cost of detecting and fixing security vulnerabilities early in the system development lifecycle is far lower than the cost of security remediation during software development and maintenance. With the continuous expansion of system scale and the increasingly close interaction between humans and technology, the role of the "human" factor in the entire system is becoming increasingly important. Each system stakeholder (i.e., system stakeholders) can be abstracted as a system component, interacting with other components (stakeholders, software systems, hardware devices, etc.) to achieve system goals. Since the most vulnerable link in a system determines its security level, security requirements analysis for large and complex systems needs to cover all system components.

[0003] Traditional security requirements analysis focuses solely on technical attacks, specifically those exploiting vulnerabilities in software and hardware (such as SQL injection and password stuffing), lacking threat analysis targeting human stakeholders. However, Mitnick, a computer security consultant known as the "world's number one hacker," explicitly points out that the "human" factor has become the greatest threat to system security, as manipulating people is actually easier than manipulating technology. This is especially true given the increasingly sophisticated technical security analysis and protection measures, while security analysis and protection against people at the social level are far from adequate. Social engineering attacks exploit human vulnerabilities to manipulate their psychology, causing them to perform specific actions or leak confidential information. Typical social engineering attacks include phishing attacks, identity spoofing, and decoy attacks.

[0004] Social engineering focuses on "people" as its core research object; people are both the perpetrators and targets of social engineering attacks. Compared to technical attacks targeting software, social engineering attacks exploit and exploit human vulnerabilities. For example, people often tend to offer helpful assistance to others, but from an attacker's perspective, this becomes a vulnerability that can be exploited to carry out social engineering attacks. Compared to the deterministic behavior of software systems, human behavior often cannot strictly follow pre-set behavioral logic. Rules imposed on people have more detailed and complex semantics, such as being responsible for doing something, being allowed to do something, or having the ability to do something. In other words, formal methods for describing software system behavior cannot be directly used to describe human behavior. Therefore, current security requirements analysis for social engineering attacks can only be conducted manually through brainstorming, rather than through comprehensive automated analysis, leaving significant security vulnerabilities in the system.

[0005] In conclusion, security requirements analysis for social engineering attacks is key to improving the overall security of large and complex systems.

[0006] Despite the interdisciplinary nature of social engineering attacks, researchers in the field of security engineering have studied them from several perspectives. First, several conceptual models of social engineering have been proposed, laying the foundation for further research. Other researchers have studied attack models of social engineering to provide a deeper understanding of these attacks, thereby raising awareness. This type of research primarily focuses on conceptualizing social engineering threats but fails to capture the complex context of the threats, thus hindering effective prediction of potential risky behavior by victims. Another branch of social engineering research focuses on identifying social engineering threats. These studies provide heuristic guidance for analyzing system context and detecting social engineering threats; however, these guidance methods can only be applied manually and therefore cannot handle the increasing complexity of modern systems. To date, there is no effective method for automatically analyzing the threat of large-scale social engineering attacks. Summary of the Invention

[0007] In order to address the aforementioned problems in existing technologies, this invention provides an automatic detection method for social engineering attacks based on multi-perspective agent modeling, which is applicable to scene modeling of large-scale complex systems and automatic detection of threats within those scenes.

[0008] This invention includes the following steps:

[0009] Step (1) Scene modeling steps:

[0010] The enterprise provides the relevant documents required for modeling. According to the conceptual model of the present invention, the scenario is modeled according to the documents, including four dimensions: organizational setup (role relationships), business objectives (target model, assets and social engineering concepts), social interaction (delegation and dependence) and human characteristics (specific roles). The scenario facts are generated. When the modeling is completed, step (2) is executed.

[0011] Step (2) Threat reasoning steps:

[0012] Existing social engineering attack detection methods rely on dialogue or text, which cannot detect security threats in complex systems. Therefore, this invention employs threat inference rules based on logical reasoning to infer scenario threats, and uses the logic programming language Prolog to automate the scenario threat inference.

[0013] Step (2.1) Scene Information Reasoning:

[0014] After step (1), based on the scene facts that have been modeled, in this step, these facts and scene reasoning rules are input into SWI-prolog to infer more comprehensive scene information.

[0015] Step (2.2) Threat Reasoning:

[0016] After step (2.1), a more comprehensive set of scenario facts is obtained. In this step, the scenario facts and threat inference rules obtained in the previous step are input into SWI-prolog to infer potential social engineering attacks in the scenario. Attached Figure Description

[0017] Figure 1 This is a flowchart of the threat detection process of the present invention.

[0018] Figure 2 This is a conceptual model diagram of the human-centered approach of the present invention.

[0019] Figure 3 This is a flowchart illustrating the modeling process of the present invention. Detailed Implementation

[0020] A brief overview of the invention is given below to provide a basic understanding of certain aspects of it. It should be understood that this overview is not an exhaustive summary of the invention. It is not intended to identify key or essential parts of the invention, nor is it intended to limit the scope of the invention. Its purpose is merely to present certain concepts in a simplified form as a prelude to the more detailed description that follows.

[0021] The automatic detection method for social engineering attacks based on multi-perspective subject modeling mentioned in this paper includes two steps: step (1) performing scene modeling and step (2) performing threat detection.

[0022] Step (1) Scene modeling steps:

[0023] Existing conceptual models reveal key concepts of social engineering attacks from different perspectives, but none are complete. This invention analyzes multiple concepts in security requirements engineering. Our conceptual model proposes four role relationships to represent organizational settings, introduces social engineering concepts such as ownership, access, authority, and obligation to strengthen the semantics of assets and tasks, introduces trust, delegation, and dependence to describe social interactions, and analyzes these from the perspective of social engineering attacks. Finally, it also analyzes the impact of human vulnerability on social engineering attacks.

[0024] In step (1), the enterprise provides the relevant documents required for modeling and models the scenario according to the content of the documents, including four dimensions: organizational setup (role relationships), business objectives (target model, assets and social engineering concepts), social interaction (delegation and dependence) and human characteristics (character roles), and generates scenario facts. When the modeling is completed, step (2) is executed.

[0025] The specific details of scene modeling in step 1 above are described below:

[0026] Step (1.1) Modeling role relationships:

[0027] The company provides organizational structure documents describing the overall work setup and management framework. Each position will be modeled as a role. First, all roles in the scenario are created. Then, relationships between roles are modeled according to the management framework, with roles being modeled as colleagues and superiors / subordinates. Next, based on the company's external collaborating roles, relevant external collaborative relationships are modeled. Roles without these three relationship models will default to a stranger relationship.

[0028] The results of the role relationship modeling include: colleague(R1,R2), subordinate(R1,R2), ex_cooperation(R1,R2), and unfamiliar(R1,R2).

[0029] Step (1.2) Modeling the target model and assets:

[0030] The company provides job description documents, describing the specific responsibilities and protected assets for each position. The goal modeling process begins with analyzing and identifying the top-level goals for each role. Next, the top-level goals are iteratively refined and decomposed into AND or OR goals until the atomic goals are directly achievable. Finally, for each goal, the assets required to achieve it and the assets generated by achieving it are analyzed. Protected assets are directly modeled as role assets.

[0031] The results of modeling the target model and assets include: task(T), AND_decomp(T,T1,T2), OR_decomp(T,T1,T2), generate(R1,T), need(R1,T).

[0032] Step (1.3) Modeling the concept of social engineering:

[0033] The company provides rules and regulations describing the usage rules for protected assets and tasks. For assets, ownership, permissions, and access status are modeled. Ownership has two states: ownership and no ownership. Access has two states: accessible (the role can remove access controls on the asset or the asset has no access controls) and inaccessible (the role cannot remove access controls on the asset). Permissions have three states: permission, uncertain permission (no explicit definition of whether a role has a certain permission), and no permission. Obligations have two states: obligation (must be performed) and no obligation (optional). During modeling, the ownership relationships of assets are first modeled according to the regulations to determine the owner of each asset. Based on this, the permission status of other roles on the assets is further modeled. The company provides access control settings for each asset to model the access status of roles on the assets. For tasks, their permission and obligation status are modeled; by default, tasks in job responsibilities have both permissions and obligations.

[0034] The modeling results for asset ownership include: ownership(R1,AS). The modeling results for asset permissions include: has_permission(R1,AS), uncertain_permission(R1,AS), and no_permission(R1,AS). The modeling results for asset access include: accessible(R1,AS) and unaccessible(R1,AS). The modeling results for task permissions include: has_permission(R1,T) and no_permission(R1,T). The modeling results for task obligations include: has_obligation(R1,T) and no_obligation(R1,T).

[0035] Step (1.4) Modeling Delegates and Dependencies:

[0036] Based on the business activity documents provided by the enterprise, we model the dependencies (one role depends on another role's asset or task to complete a task) and delegations (delegation of assets: one role delegates the authority or obligation of an asset to another role; delegation of tasks: one role delegates the authority or obligation of a task to another role) in the social dimension, and generate the facts of delegation and dependency in the scenario.

[0037] The modeling results for delegation include: delegate_p(R1,R2,AS), delegate_o(R1,R2,AS), delegate_p(R1,R2,T), and delegate_o(R1,R2,T). The modeling results for dependency include: depend(R2,T,AS1,R1) and depend(R2,T,T1,R1).

[0038] Step (1.5) Select a character:

[0039] Choose an agent with specific abilities (the ability to complete a task), personality traits (8 personality traits), and security awareness (three levels: high, medium, and low). Demonstrate how social engineering attacks can occur on a specific agent by having the agent play a role.

[0040] The modeling results in this step include: play(A1,R1), capable(A1,T), has_personality(A1,_), has_security_awareness(A2,L).

[0041] Step (2) Threat reasoning steps:

[0042] Existing social engineering attack detection methods rely on dialogue or text, which cannot detect security threats in complex systems. Therefore, this invention employs threat inference rules based on logical reasoning to infer scenario threats, and uses the logic programming language Prolog to automate the scenario threat inference.

[0043] Step (2.1) Scene Information Reasoning:

[0044] Following step (1), based on the already modeled scene facts, this step inputs these facts and scene reasoning rules into SWI-prolog to reason about other scene information. Then, the modeled scene information and the reasoned scene information are integrated to form a more comprehensive scene information. The formal scene reasoning rules proposed in this paper are shown in Table 1. The scene reasoning rules of this invention are designed from four aspects: role relationships, the implication relationship between ownership, access, authority and obligation, delegation relationship and trust establishment.

[0045] Step (2.2) Threat Reasoning:

[0046] Following step (2.1), a relatively comprehensive set of scenario facts is obtained. In this step, the scenario facts and threat inference rules obtained in the previous step are input into SWI-prolog. By inputting the assets of a certain role to be detected, the system infers which social engineering attacks this asset might be subject to in the current scenario. The formal threat inference rules proposed in this paper are shown in Table 2. Based on the classification of existing research, this invention selects nine social engineering attack techniques as the results of threat detection and classifies the probability of threats into three levels: high, medium, and low. The scenario inference rules are designed from five aspects: based on access, based on trust, based on permissions, based on dependence, and based on personality characteristics.

[0047] Table 1. Scenario Reasoning Rules

[0048] 角色关系 •同事(R1, R3) ← 同事(R1, R2) ∧ 同事(R2, R3) •下属(R1, R3) ← 下属(R1, R2) ∧ 下属(R2, R3) •前合作关系(R1, R3) ← 同事(R1, R2) ∧ 前合作关系(R2, R3) •前合作关系(R1, R3) ← 下属(R1, R2) ∧ 前合作关系(R2, R3) •下属(R1, R3) ← 下属(R1, R2) ∧ 同事(R2, R3) •下属 (R1, R3) ← 下属(R1, R2) ∧ 同事(R1, R3 所有权、访问、权限和义务 •具有权限(R1, AS) ← 拥有所有权(R1, AS) •可访问(R1, AS) ← 具有权限(R1, AS) •具有权限(R1, T) ← 负有义务(R1, T) •具有权限(R1, AS) ← 负有义务(R1, T) ∧ 需要(T, AS) •具有权限(R1, AS) ← 具有权限(R1, T) ∧ 需要(T, AS) •具有权限(R1, AS) ← 负有义务(R1, T) ∧ 生成(T, AS) •具有权限(R1, AS) ← 具有权限(R1, T) ∧ 生成(T, AS) 委托 •has_permission(R2,AS) ←has_permission(R1,AS)∧delegate_p(R1,R2,AS)•has_ obligation(R2,AS) ←has_obligation(R1,AS)∧delegate_o(R1,R2,AS)•has_ permission(R2,T) ←has_permission(R1,T)∧delegate_p(R1,R2,T)•has_obligation(R2,T) ←has_obligation(R1,T)∧delegate_o(R1,R2,T)•delegate_p(R1,R2,AS) ←has_permission(R1,T)∧delegate_p(R1,R2,T)∧need(T,AS)•delegate_p(R1,R2,AS) ←has_obligation(R1,T)∧delegate_o(R1,R2,T)∧need(T,AS) Trust •trust(A2,A1,l) ←(subordinate(R1,R2)∨colleague(R1,R2)∨ex_cooperation(R1,R2))∧play(attacker,R1)∧play(A2,R2)∧has_security_awareness(A2,h)•trust(A2,A1,h) ←(subordinate(R1,R2)∨colleague(R1,R2)∨ex_cooperation(R1,R2))∧play(attacker,R1)∧play(A2,R2)∧has_security_awareness(A2,l)•trust(A2,A1,m) ←(subordinate(R1,R2)∨colleague(R1,R2)∨ex_cooperation(R1,R2))∧play(attacker,R1)∧play(A2,R2)∧has_security_awareness(A2,m)•trust(A2,A1,h) ←unfamiliar(R1,R2)∧play(A1,R1)∧play(A2,R2)∧has_security_awareness(A2,m)•trust(A2,A1,m) ←subordinate(R1,R2)∧play(attacker,R1)∧play(A2,R2)∧has_security_awareness(A2,l)∧has_personality(A2,fear_of_unknown)

[0049] Table 2 Threat Detection Rules

[0050] Access-based threat detection rules •accessible(R1,AS)∧no_permission(R1,AS)∧ownership(R2,AS)∧play(A2,R2)∧(has_personality(A2,thoughtlessness)∨has_personality(A2,apathy))∧has_security_awareness(A2,L)→shoulder_surfing(R1,A2,AS,l)•accessible(R2,AS)∧(no_permission(R1,AS)∨uncertain_permission(R1,AS))∧play(A2,R2)∧(has_personality(A2,thoughtlessness)∨has_personality(A2,apathy))∧has_security_awareness(A2,L)→attack(tailgating,A1,A2,AS,L) Trust-based threat detection •(no_permission(R1,AS)∨uncertain_permission(R1,AS))∧(has_permission(R2,AS)∨ownership(R2,AS))∧(subordinate(R1,R2)∨ex_cooperation(R1,R2))∧play(attacker,R1)∧play(A2,R2)∧trust(A2,attacker,L)∧(has_personality(A2,greed)∨has_personality(A2,gullibility)∨has_personality(A2,curiosity))→attack(incentive,attacker,A2,AS,L)•(no_permission(R1,AS)∨uncertain_permission(R1,AS))∧subordinate(R1,R2)∧play(attacker,R1)∧play(A2,R2)∧trust(A2,attacker,L)∧capable(R2,AS)∧generate(T,AS)∧(has_personality(A2,gullibility)∨has_personality(A2,fear_of_unknown))→attack(intimidation,attacker,A2,AS,L) Permission-based threat detection •(subordinate(R1,R2)∨colleague(R1,R2)∨ex_cooperation(R1,R2))∧ownership(R2,AS)∧has_permission(R1,AS)∧depend(R1,T,AS,R2)∧play(attacker,R1)∧play(A2,R2)∧(has_personality(A2,diffusion_of_responsibility)∨has_personality(A2,gullibility)∨has_personality(A2,thoughtlessness))∧has_security_awareness(A2,m)→impersonation(A1,A2,AS,m)•(subordinate(R1,R2)∨colleague(R1,R2)∨ex_cooperation(R1,R2))∧has_permission(R1,AS)∧has_obligation(R1,T)∧need(T,AS)∧ownership(R2,AS)∧unfamiliar(R1,R3)∧play(A1,R3)∧play(A2,R2)∧(has_personality(A2,diffusion_of_responsibility)∨has_personality(A2,gullibility)∨has_personality(A2,thoughtlessness))∧has_security_awareness(A2,h)→impersonation(A1,A2,AS,l) Dependence-based threat detection •(no_permission(R1,AS)∨uncertain_permission(R1,AS))∧ownership(R2,AS)∧(subordinate(R1,R2)∨colleague(R1,R2)∨ex_cooperation(R1,R2))∧has_obligation(R2,T)∧depend(R2,T,AS1,R1)∧ownership(R1,AS1)∧play(attacker,R1)∧play(A2,R2)∧trust(A2,attacker,L)∧(has_personality(A2,courtesy)∨has_personality(A2,gullibility)∨(has_personality(A2,diffusion_of_responsibility))→reverse_social_engineering(A1,A2,AS,L)•(no_permission(R1,AS)∨uncertain_permission(R1,AS))∧(subordinate(R1,R2)∨colleague(R1,R2)∨ex_cooperation(R1,R2))∧has_obligation(R2,T)∧depend(R2,T,AS1,R1)∧ownership(R1,AS1)∧play(attacker,R1)∧play(A2,R2)∧capable(A2,T1)∧generate(T1,AS)∧trust(A2,attacker,L)∧(has_personality(A2,courtesy)∨has_personality(A2,gullibility)∨(has_personality(A2,diffusion_of_responsibility))→reverse_social_engineering(A1,A2,AS,L) Personality-based threat detection •(no_permission(R1,AS)∨uncertain_permission(R1,AS))∧ownership(R2,AS)∧play(attacker,R1)∧play(A2,R2)∧(has_personality(A2,thoughtlessness)∨has_personality(A2,apathy))∧has_security_awareness(A2,L)→attack(dumpster_diving,A1,A2,AS,L)

Claims

1. An automatic detection method for social engineering attacks based on multi-view subject modeling, characterized in that, Includes the following steps: Step (1) Scene modeling steps: The enterprise provides relevant documents required for modeling. Based on the conceptual model, the scene is modeled according to this document, including four dimensions: organizational setup, business objectives, social interaction and human characteristics. The scene facts are generated. When the modeling is completed, step (2) is executed. Step (2) Threat reasoning steps: Use logic-based threat reasoning rules to reason about scenario threats, and use the logic programming language Prolog to realize automated reasoning of scenario threats; Step (2.1) Scene Information Reasoning: Based on the scene facts that have been modeled, these facts and scene reasoning rules are input into SWI-prolog to reason other scene information. Then, the modeled scene information and the reasoned scene information are integrated to form a more comprehensive scene information. The scene reasoning rules are designed from four aspects: role relationships, the implied relationship between ownership, access, permissions and obligations, delegation relationship and trust establishment. Step (2.2) Threat Inference: After step (2.1), a comprehensive scene fact is obtained; the obtained scene fact and threat inference rules are input into SWI-prolog, and by inputting the assets of a certain role to be detected, the social engineering attacks that the asset may be subject to in the current scene are inferred; according to the classification of existing research, nine social engineering attack techniques are selected as the results of threat detection, and the probability of the threat is divided into three levels: high, medium and low. The scenario reasoning rules are designed from five aspects: based on access, based on trust, based on permissions, based on dependency, and based on individual characteristics. The specific details of scene modeling in step (1) above are described below: Step (1.1) Modeling role relationships: The enterprise provides an organizational setup file that describes the overall work setup and management framework of the enterprise; each position will be modeled as a role; first, all roles in the scenario are created, and then the relationships between roles are modeled according to the management framework. Roles will be modeled as colleagues and superiors / subordinates; then, based on the enterprise's external cooperation roles, relevant external cooperation relationships are modeled, and other roles that do not have these three types of relationships modeled will be assumed to be strangers. The results of the role relationship modeling include: colleague(R1,R2), subordinate(R1,R2), ex_cooperation(R1,R2), and unfamiliar(R1,R2); Step (1.2) Modeling the target model and assets: The company provides job description documents, describing the specific job responsibilities and protected assets for each position; the modeling of the target will begin with analyzing and identifying the top-level target for each role; next, the top-level target will be iteratively refined and decomposed into "AND" targets or "OR" targets until the atomic target can be directly achieved; finally, for each target, the assets required to achieve the target and the assets generated by achieving the target will be analyzed; the protected assets are directly modeled as role assets. The results of modeling the target model and assets include: task(T), AND_decomp(T,T1,T2), OR_decomp(T,T1,T2), generate(R1,T), need(R1,T).

2. The automatic detection method for social engineering attacks based on multi-view subject modeling according to claim 1, characterized in that, Step (1) also includes: Step (1.3) Modeling the concept of social engineering: The company provides rules and regulations documents describing the usage rules for protected assets and tasks. For assets, ownership, permissions, and access status are modeled. Ownership has two states: ownership and no ownership. Access has two states: accessible and inaccessible. Permissions have three states: permission granted, permission uncertain, and no permission. Obligations have two states: obligation granted and no obligation. During modeling, the ownership relationship of assets is first modeled according to the regulations to determine the owner of each asset. Based on this, the permission status of other roles to assets is further modeled. The company provides access control settings for each asset to model the access status of roles to assets. For tasks, their permission and obligation status are modeled; by default, tasks in job responsibilities have both permissions and obligations. The modeling results for asset ownership include: ownership(R1,AS); the modeling results for asset permissions include: has_permission(R1,AS), uncertain_permission(R1,AS), no_permission(R1,AS); the modeling results for asset access include: accessible(R1,AS), unaccessible(R1,AS); the modeling results for task permissions include: has_permission(R1,T), no_permission(R1,T); and the modeling results for task obligations include: has_obligation(R1,T), no_obligation(R1,T). Step (1.4) Modeling Delegates and Dependencies: Based on the business activity documents provided by the enterprise, the dependencies and delegations in the social dimension are modeled to generate facts of delegation and dependence in the scenario; The modeling results for delegation include: delegate_p(R1,R2,AS), delegate_o(R1,R2,AS), delegate_p(R1,R2,T), delegate_o(R1,R2,T); the modeling results for dependency include: depend(R2,T,AS1,R1), depend(R2,T,T1,R1). Step (1.5) Select a character: Select individuals with specific abilities, personality traits, and security awareness, and demonstrate how social engineering attacks can occur on specific individuals by having them play a certain role. The modeling results include: play(A1,R1), capable(A1,T), has_personality(A1,_), and has_security_awareness(A2,L).

Images