A dynamic embedded system network security scene modeling and threat analysis method and system

Abstract

The application discloses a kind of dynamic embedded system network security scene modeling and threat analysis method and system, including the following steps: scene construction, for constructing scene graph data;Dynamic simulation, for visual presentation to scene model;Automatic threat identification, for constructing attack path or threat correlation diagram;Threat intelligence correlation, for matching threat item with vulnerability intelligence data;Risk rating and model improvement, for improving scene model;Threat model visualization, for superimposed visualization display of threat analysis result;Report generation and export, for automatically generating and exporting security analysis report;Model management, for centralized storage and collaborative management.The application realizes full-dimensional threat identification to embedded system software, network, hardware and physical attack, greatly improves the comprehensiveness, accuracy and analysis efficiency of threat analysis, effectively solves the problem that traditional method is not fully covered, high artificial dependence, risk assessment is not accurate.

Description

Technical Field

[0001] This invention relates to the field of embedded system information security engineering, specifically to a method and system for dynamic embedded system network security scenario modeling and threat analysis. Background Technology

[0002] With the widespread application of IoT technology and embedded systems, embedded devices are now widely used in key areas such as automotive electronics, industrial control, drones, and smart homes. Embedded systems typically consist of sensors, control units, communication buses, gateway devices, firmware, operating systems, and application software. Their network structures are complex, their external interfaces are diverse, and they generally suffer from limited computing resources and weak security mechanisms. They face security risks such as identity spoofing, data tampering, information leakage, denial-of-service attacks, firmware cracking, physical attacks, and vulnerability exploitation, posing a serious threat to system reliability and data security. Therefore, conducting comprehensive and accurate network security threat modeling and analysis during the design, development, and deployment phases of embedded systems is of great significance for improving system security capabilities.

[0003] Currently, security threat analysis methods for embedded systems often employ data flow graphs combined with STRIDE models, attack tree models, and manual vulnerability verification. While these methods can identify security threats to a certain extent, they have several shortcomings in practical applications:

[0004] Scenario modeling mainly relies on static two-dimensional charts or text descriptions, lacking dynamic interaction and three-dimensional visualization simulation capabilities. It cannot intuitively display the interaction relationships between embedded system components and the evolution process of attack paths, which is not conducive to security analysts quickly identifying system vulnerabilities.

[0005] Threat analysis has a limited scope, focusing primarily on threat identification at the software architecture and network communication levels. It lacks targeted analysis of hardware buses, firmware, security chips, debugging interfaces, and physical attacks specific to embedded systems, which can easily lead to the omission of key threat points.

[0006] The analysis process has a low degree of automation, relies heavily on manual operation by security experts, has low analysis efficiency, is prone to human error, and is difficult to link with real-time vulnerability intelligence and attack case databases, resulting in insufficient accuracy of risk assessment results.

[0007] The lack of a unified model management platform makes it difficult to reuse scenario models and analysis results, and inconvenient for collaborative editing, failing to meet the security analysis needs of multiple personnel, multiple projects, and multiple version iterations.

[0008] In summary, existing threat modeling and analysis methods are ill-suited to the structural characteristics and security requirements of embedded systems, and cannot achieve dynamic, comprehensive, automated, and visualized security threat analysis. Therefore, there is an urgent need for a dynamic embedded system network security scenario modeling and threat analysis solution that can address the above issues. Summary of the Invention

[0009] The purpose of this invention is to provide a method and system for dynamic embedded system network security scenario modeling and threat analysis, so as to solve the problems mentioned in the background art.

[0010] To achieve the above objectives, the present invention provides the following technical solution:

[0011] A method for modeling and analyzing network security scenarios in dynamic embedded systems includes the following steps:

[0012] Step S1, Scenario Construction: Users construct a business scenario model of the target embedded system through a visual interface. Specifically, they can select corresponding embedded devices and network components from the component library. For example, in an automotive electronics scenario, users can add ECU control units, CAN buses, in-vehicle Ethernet switches, sensors, and actuator nodes, and use lines to represent the communication connections between them; in a drone system scenario, they can add flight control boards, navigation modules, radio communication links, etc. Users can also set attribute parameters for each node, such as the device's operating system type, firmware version, network protocol, IP address, open port list, security chip model, etc. After the scenario is built, the scenario model data is saved. This data comprehensively depicts the system's composition and structural relationships, laying the foundation for subsequent threat analysis.

[0013] Step S2: Dynamic Simulation. The system launches the 3D rendering engine to visualize the aforementioned scene model in 3D. The user interface displays an interactive 3D scene: device nodes appear in the virtual 3D space as models or icons, arranged according to their layout relationships in the real environment, and the nodes are connected by lines or physical links. Users can freely rotate, pan, and zoom the viewpoint to observe the entire system architecture. Simultaneously, the system initializes the scene model in the background, including establishing a node topology graph and loading threat rules related to the scene from the knowledge base.

[0014] Step S3: Automatic Threat Identification. Users can initiate threat modeling and analysis with a single click. The system's threat analysis engine performs a comprehensive security threat enumeration of all asset objects in the scenario model. The engine will select an appropriate analysis strategy based on the nature of each object.

[0015] For bus and communication modules: For bus and network interfaces such as CAN, UART, SPI, and Ethernet, the STRIDE model is applied to check for possible threat categories. For example, there may be risks to bus communication such as tampering (e.g., data being maliciously modified), information leakage (e.g., sensitive data being eavesdropped on), and denial-of-service (e.g., bus flooding causing communication interruption of legitimate nodes). The engine will match these risks with common bus attack patterns (e.g., bus arbitration spoofing, replay attacks, etc.) in the knowledge base and record the potential threat points found.

[0016] For firmware and operating systems: For the firmware and operating systems of embedded devices, known vulnerability pattern matching and attack tree analysis are employed. The engine checks the firmware version, matches it with known vulnerabilities (e.g., whether there are publicly disclosed CVE vulnerabilities targeting this version), and analyzes the firmware's security mechanisms (e.g., boot verification, debugging interfaces). The attack tree algorithm is used to deduce attack paths: assuming an attacker starts with the firmware, what are the possible steps (e.g., implanting a Trojan -> bypassing signature verification -> gaining system control).

[0017] For security chips and hardware: For security chips, encryption modules, or hardware interfaces (such as JTAG debug ports, USB interfaces, etc.) in a device, the analysis engine identifies physical attack threats based on knowledge base entries. For example, JTAG interfaces could be abused to read firmware or inject code, while USB interfaces could lead to malicious device attacks. For security encryption chips, the engine analyzes their key management and physical protection to identify potential advanced threats such as side-channel attacks and fault injection.

[0018] For application software and communication protocols: For embedded application layer software (such as in-vehicle entertainment system software, web services in IoT devices) and the communication protocols used, threat identification is performed by combining data flow graphs and attack trees. Data flow graph analysis helps identify the boundaries of data flow and examines sensitive data for potential attacks during transmission or processing (such as identity spoofing requests, privilege escalation attempts, etc.). Attack trees can start from the attacker's goal (such as gaining administrator privileges, hijacking device control), and deduce possible branching steps (such as injecting malicious commands, buffer overflow exploits, etc.).

[0019] Through the multi-layered and multi-method analysis described above, the system generates a threat list for each asset node, listing all identified potential threats. For each threat, it records information such as its type, possible attack methods, and scope of impact. Furthermore, the analysis engine integrates the relationships between various threats to construct attack paths or threat relationship graphs.

[0020] Step S4, Threat Intelligence Association: After the threat list is generated, the system automatically matches and associates each threat item with the real-time updated vulnerability intelligence database. For each threat, the analysis engine extracts its relevant elements (such as the type of device or protocol involved, the type of vulnerability that may be exploited, and the conditions required for the attack), and searches the vulnerability intelligence database. If a corresponding known vulnerability exists, the vulnerability information is associated with the threat item. The associated information includes the vulnerability number (e.g., CVE number), vulnerability name, public description, vulnerability severity score (CVSS score), and known exploit code or reference links. If a threat corresponds to multiple related vulnerabilities or attack cases, the system will list all intelligence entries with brief descriptions. Simultaneously, the system checks the historical attack cases corresponding to the threat item; if a match is found, the case name and occurrence time are recorded. For new threats not yet included in the database, the analysis engine marks them as "unknown threats," prompting the user to submit the threat and its details to the intelligence database for expansion.

[0021] Step S5, Risk Rating and Model Improvement: The system performs risk scoring calculations for each identified and associated threat item. First, the CVSS calculation module is invoked to calculate a baseline score based on various vulnerability indicators (attack difficulty, impact scope, exploit complexity, etc.). Simultaneously, the DREAD model is invoked to subjectively score the threat (e.g., assessing the potential damage, exploit difficulty, and other aspects based on the knowledge base). If an OWASP risk scoring standard is applicable to the threat, its score on probability of occurrence and impact is also considered. The system normalizes the results from these multiple models and then determines the final level according to a predetermined strategy: a weighted average can be used to obtain a comprehensive score, which is then mapped to high / medium / low levels; or the most severe level from multiple models can be directly taken as the final level, emphasizing a conservative security principle. After prioritizing the threats, the system checks the model completeness. For threats rated as high-risk, the analysis engine backtracks and checks the scenario model and threat model to ensure that all relevant security elements are covered. Users can then refine the scenario model based on prompts (e.g., adding additional security components or adjusting connection relationships) and choose to rerun the threat analysis to obtain more accurate and complete results.

[0022] Step S6, Threat Model Visualization: After threat identification and risk assessment are completed, the system generates a corresponding threat model visualization view, which is overlaid on the scenario model to help users intuitively understand the security posture. The main visualization content includes:

[0023] Attack entry point highlighting: If the analysis finds that certain components are possible initial entry points for attackers (such as external interface devices, gateways exposed to the Internet, etc.), these components will be highlighted in the 3D scene with a special color or flashing effect to indicate where the attack may first occur.

[0024] High-risk equipment labeling: Nodes in the scene assessed as high-risk will be marked with a special icon, such as a red warning symbol next to the equipment icon. Medium-risk equipment is marked in yellow, and low-risk equipment may not be specially marked or may be marked in green, to visually distinguish the risk level.

[0025] Attack chains and multiple threat associations: Potential attack paths are marked in the scenario using lines and arrows. For example, starting from a high-risk entry point, arrows point to the next node it can attack, forming a possible attack chain. For complex attacks involving multiple steps (such as physical intrusion -> firmware control -> lateral movement to the communication network -> final control of critical modules), these paths are shown as a continuous arrow chain on the graph. If a node is affected by multiple related threats, multiple threat lines converge at that node, and different types of threats can be distinguished by different colors or line types.

[0026] Interactive Detailed View: Users can click on any threat marker, and the system will pop up a detailed information panel for that threat, including: threat description, target assets, specific vulnerability IDs and names that may be exploited, required attack techniques, and recommended defense measures. Through this interactive interface, users can directly access complete information about each threat on the scenario diagram without having to consult reports.

[0027] Step S7, Report Generation and Export: While conducting visual analysis, the system automatically summarizes all results and generates a detailed threat analysis report. The report includes the following main contents:

[0028] Scenario Summary: Provide a textual description of the model scenario, such as the types of equipment included in the system, topology, key assets, as well as the scope of analysis and assumptions.

[0029] Asset List: Lists all major asset nodes in the scenario and their attribute information to help readers understand the system composition.

[0030] Threat List and Details: All identified threats are listed categorized by threat level. A detailed description is provided for each threat, including the attack methods, target assets, and potential consequences. If associated vulnerability intelligence, the corresponding vulnerability ID, name, and CVSS score, along with links to existing exploit code or references, are provided under each threat. For each threat, the report also offers security recommendations (from knowledge bases and intelligence repositories, such as recommended patches, configuration hardening, and intrusion detection methods).

[0031] Risk assessment results: A summary of the overall security situation, including the number of high-risk threats, their main distribution locations, and the system's risk index score.

[0032] Attached diagrams and attack illustrations: The report includes key visualizations captured from the system interface, such as a 3D threat landscape diagram and illustrations of typical attack paths.

[0033] Conclusions and Recommendations: The overall security of the system is evaluated, the most critical weaknesses that require priority attention are identified, and a list of recommended improvement measures is provided.

[0034] The report can be exported as a PDF or Word document with a single click through the system interface for archiving or provision to decision-makers.

[0035] Step S8, Model Management: All constructed scenario models and corresponding generated threat models are saved in the system's centralized management library for future retrieval and reuse. Users can add names, tags, and descriptions to models created for each analysis for easy future retrieval. For example, models can be categorized and stored according to device type or project name. The system supports model import / export functions, facilitating the sharing of model data between different projects or users. When users need to review the same system or simulate new threats, they can copy existing models from the library for modification without having to rebuild the scenario from scratch. Furthermore, the model library has a version control mechanism: whenever a user modifies and saves a model, the system records a version snapshot and modification history for future auditing and comparison of the security status of different versions. For multi-user collaboration, this invention provides access control and locking mechanisms to prevent conflicts from multiple users editing simultaneously and allows members with different permissions to browse or edit models.

[0036] A dynamic embedded system network security scenario modeling and threat analysis system, comprising:

[0037] The scene modeling module is used to execute step S1. This module provides a graphical interface for building a security scene model. Users can drag and drop icons representing various embedded devices or network components (such as control boards, sensor nodes, bus lines, communication gateways, etc.) from the component library to the workspace and establish connections between them. The component library includes icons for control boards, sensor nodes, bus lines, communication gateways, etc. Node attributes include hardware type, operating system, firmware version, communication protocol, IP address, open port list, security chip model, etc. This module converts the user-built scene into a scene graph data structure, recording each node and its attributes, as well as the connections / dependencies between nodes.

[0038] A threat analysis engine is used to execute step S3. The threat analysis engine is the core analysis module, including a pre-built threat identification algorithm library and knowledge base. The engine reads scenario graph data and performs security analysis on each asset node and its connections. It integrates multiple threat modeling methods, specifically including:

[0039] The STRIDE model is used to analyze common network and software threats, classifying them into six categories: identity impersonation, tampering, denial of responsibility, information disclosure, denial of service, and privilege escalation.

[0040] Attack tree algorithm, which is used to deduce complex attack paths, describes the various means and paths that an attacker takes to achieve a certain goal in a tree-like hierarchical manner. The root node of the tree is the attack target, and the branches represent different combinations of attack methods.

[0041] Data flow diagrams, which are used to identify risk points in data interactions, are diagrams illustrating the flow of data between different processing components in a modeling system.

[0042] The OWASP Security Guide is used to identify common vulnerability patterns, such as authentication bypass, code injection, and weak encryption, which are listed in the OWASP Top 10.

[0043] The knowledge base stores common threat patterns and attack methods for different types of objects, so that the engine can match them accordingly.

[0044] A vulnerability intelligence database is used to provide intelligence data for step S4. The vulnerability intelligence database stores information from real-time updated vulnerability intelligence, including publicly available vulnerability lists (such as CVE databases), known attack case libraries (such as tactical entries in the ATT&CK framework), and corresponding mitigation recommendations. ATT&CK is an abbreviation for Adversarial Tactics, Techniques & Common Knowledge. This invention can integrate this database or connect to external intelligence sources via an API interface. The analysis engine will utilize this database to correlate identified potential threats with recorded vulnerabilities or attack records.

[0045] A risk assessment module is used to execute step S5. This module quantifies and rates threats, and implements various risk assessment models, including:

[0046] CVSS calculates a baseline score based on indicators such as attack difficulty, impact scope, and exploit complexity. The score ranges from 0 to 10. The score is calculated from multiple indicators such as vulnerability exploitation difficulty, authentication requirements, and impact scope, and is divided into three dimensions: base score, time score, and environment score.

[0047] The DREAD model scores threats based on five dimensions: damage level, reproducibility, exploitability, scope of affected users, and discoverability.

[0048] OWASP is a risk scoring methodology that comprehensively rates vulnerabilities based on factors such as vulnerability nature, potential impact, exploitation difficulty, and likelihood of attack.

[0049] Once the threat analysis engine generates a threat list, the risk assessment module calculates a score for each threat and combines the results from different models to give the severity level of the threat.

[0050] The visualization rendering module is used to execute steps S2 and S6. This module is responsible for presenting the scene model and threat analysis results on the front-end interface. A 3D graphics engine is used to render the scene data into a 3D interactive environment. During rendering, high-risk components are highlighted with prominent colors, attack paths associated with threats are marked with lines, and specific icons or markers are overlaid on threat nodes to indicate the threat type and level. Users can view the system structure and threat distribution from different perspectives through rotation, zoom, and click operations.

[0051] The report generation and model management module is used to execute steps S7 and S8. This module automatically generates a threat analysis report after the analysis is completed and manages the saving and loading of models. The report generation section compiles and exports a document (supporting PDF, HTML, and other formats) according to a predefined template, including a scenario overview, asset list, threat details, risk assessment results, and security recommendations. The model management section provides centralized storage for models and supports model retrieval, version control, and collaborative editing by teams.

[0052] Compared with the prior art, the beneficial effects of the present invention are:

[0053] 1. This invention achieves full-dimensional threat identification of embedded system software, network, hardware and physical attacks through three-dimensional interactive dynamic modeling and multi-strategy automated threat analysis. Combined with multi-model quantitative rating and vulnerability intelligence correlation, it greatly improves the comprehensiveness, accuracy and efficiency of threat analysis, and effectively solves the problems of incomplete coverage, high dependence on manual labor and inaccurate risk assessment of traditional methods.

[0054] 2. This invention, through three-dimensional visualization of the situation and centralized model collaborative management, can intuitively display attack entry points, risk levels and attack paths. It also supports model reuse, version control and automatic report export, significantly improving the intuitiveness and collaborative efficiency of security analysis, and adapting to the security assessment and continuous operation needs of embedded systems throughout their entire lifecycle. Attached Figure Description

[0055] Figure 1 This is a diagram of the overall system architecture of the present invention;

[0056] Figure 2This is a schematic diagram of the overall process of the present invention. Detailed Implementation

[0057] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0058] Example 1

[0059] like Figure 1 As shown, the automotive electronics scenario is implemented based on dynamic embedded system network security scenario modeling and threat analysis:

[0060] Step 101: Scene Construction. Users construct automotive electronic scene models through a visual interface. Select icons from the component library, such as ECU control unit, vehicle Ethernet switch, CAN bus gateway, sensor nodes, actuator nodes, and infotainment system control module, and drag them to the workspace. Use lines to represent the communication connections between the ECU and the CAN bus gateway, the connections between the CAN bus gateway and each sensor node, and the connections between the vehicle Ethernet switch and the infotainment system control module. Set attributes for each node: the ECU's operating system type is AUTOSAR, and the firmware version is V2.1; the CAN bus gateway's communication protocol is CAN2.0B, and the open port is 5000; sensor nodes include temperature sensors, tire pressure sensors, etc.

[0061] Step 102: Dynamic Simulation. The 3D rendering engine is activated, and device nodes appear as 3D models in the virtual space, arranged according to the internal layout of the car. The user rotates the view to view the ECU layout in the engine compartment, observes the CAN bus routing, and confirms the physical positional relationships between the components.

[0062] Step 103: Automatic Threat Identification. Initiate threat modeling and analysis; the threat analysis engine enumerates threats to asset objects in the scenario:

[0063] For CAN bus gateways, the STRIDE model is applied to analyze and identify tampering threats (CAN bus data can be maliciously modified), information leakage threats (CAN bus data can be eavesdropped on), and denial-of-service threats (CAN bus flooding attacks). This is then matched against bus arbitration spoofing and replay attack patterns found in the knowledge base.

[0064] For the ECU firmware, known vulnerability pattern matching was used, and a known public vulnerability was found in firmware version V2.1. Attack tree analysis was used to deduce the attack path: physical access -> firmware extraction -> vulnerability analysis -> malicious code implantation -> bypassing signature verification -> gaining control of the ECU.

[0065] For the entertainment system control module, common vulnerabilities such as authentication bypass and code injection were identified by comprehensively using data flow diagrams and OWASP methods.

[0066] The system generates a threat list for each asset node and constructs an attack path map: for example, starting from a vulnerability in the entertainment system control module, passing through the vehicle Ethernet, reaching the CAN bus gateway, and ultimately affecting the ECU control.

[0067] Step 104: Threat Intelligence Correlation. The system matches identified threats with the vulnerability intelligence database. A tampering threat to the CAN bus gateway is found and correlated with a publicly disclosed vulnerability that allows attackers to inject malicious messages via the CAN bus. The vulnerability's name, description, CVSS score of 7.5 (high risk), and known exploit code links are correlated. Simultaneously, it is correlated with publicly disclosed historical cases of similar bus attacks leading to vehicle control anomalies.

[0068] Step 105: Risk Rating and Model Refinement. The CVSS score yields a baseline score of 7.5, while the DREAD score indicates a damage severity of 9 and an exploitation difficulty of 7. The overall risk level is determined to be high. The system prompts the user to confirm whether to add a security gateway node to the model to protect against this threat. The user selects to add a CAN bus security gateway.

[0069] Step 106: Threat Model Visualization. In the 3D model of the automotive electronics scenario, the CAN bus gateway is marked with a red warning symbol, indicating high risk. Starting from the CAN bus gateway, a red arrow connects to the ECU, representing the attack path. Clicking on the CAN bus gateway displays a detailed information panel: corresponding public vulnerabilities, CAN bus tampering attacks, and a security recommendation to use bus message signature verification.

[0070] Step 107: Report Generation and Export. An automotive electronic system threat analysis report is automatically generated, including a scenario overview (the system contains 5 main components), an asset list (ECU, CAN gateway, etc.), a threat list (categorized by high, medium, and low risk), corresponding vulnerability details, risk assessment results (1 high-risk threat and 3 medium-risk threats), an attack path diagram, conclusions, and recommendations (suggestions include adding a CAN bus security gateway and upgrading ECU firmware). The report is exported as a PDF document.

[0071] Step 108: Model Management. Save the automotive electronics scenario model to the model library and add the tags "Automotive Electronics" and "2024 Assessment". Version History: V1.0 initial version, V1.1 added security gateway node.

[0072] Example 2

[0073] like Figure 2 As shown, the implementation of a drone control system based on dynamic embedded system network security scenario modeling and threat analysis is presented:

[0074] Step 201: Scene Construction. The user constructs the UAV control system scene. Select icons from the component library, including the flight controller board, navigation module, radio communication link, ground control station, and power system controller, drag and drop them into the workspace, and establish connections. Set the node properties: the flight controller board's firmware version is PX4v1.14, and the operating system is Nuttx; the navigation module uses GPS and inertial navigation; the radio communication link uses the MAVLink protocol.

[0075] Step 202: Dynamic Simulation. Start the 3D rendering engine to display the positional relationships of each component in the shape of the drone. The user zooms in and out to view the connection between the flight control board and the power system controller, and observes the coverage area of ​​the radio communication link.

[0076] Step 203: Automatic Threat Identification. Vulnerability matching was performed on the flight controller firmware, revealing a known vulnerability in PX4v1.14. The radio communication link was analyzed using the STRIDE model, identifying identity spoofing threats (forging ground control station commands), information leakage threats (interception of communication data), and denial-of-service threats (communication interference). The navigation module was analyzed for GPS spoofing and inertial navigation interference attacks.

[0077] Step 204: Threat Intelligence Association. Associate the flight controller firmware vulnerability with the CVE database and obtain the CVSS score. Associate radio communication threats with historical attack cases of the MAVLink protocol.

[0078] Step 205: Risk Assessment and Model Improvement. Based on the comprehensive scoring, radio communication identity spoofing is determined to be high-risk, and navigation module interference is determined to be medium-risk. The system recommends adding communication encryption and frequency hopping functionality.

[0079] Step 206: Threat Model Visualization. High-risk components, such as radio communication links, are marked in red. The attack path starting from the radio communication link is shown: forged control commands -> hijacking drone control -> forced landing or deviation from the flight path.

[0080] Step 207: Report Generation and Export. Generate a threat analysis report for the UAV control system, including radio communication security recommendations, flight controller firmware upgrade recommendations, etc.

[0081] Example 3

[0082] Alternative implementation methods for network security scenario modeling and threat analysis in dynamic embedded systems:

[0083] Scene modeling interface alternatives: In addition to using a 3D graphical interface, scene modeling can also be completed through script definition or configuration file import. For example, users can pre-write a scene configuration list using a description language, and the system can directly generate the model after reading it.

[0084] Visualization variations: In resource-constrained environments, basic functionality can be achieved using two-dimensional floor plans or web-based interactive interfaces. Using topology diagrams with colors and arrows to mark threats can also effectively represent attack paths and risk distribution.

[0085] Threat analysis method alternatives: Technical and tactical knowledge from the MITREATT&CK framework can be introduced to replace or supplement attack tree analysis. For communication protocol security, a fuzz testing engine can be added for robustness testing; for hardware security, an electromagnetic side-channel analysis module can be introduced to detect the physical leakage risk of encryption chips.

[0086] Risk assessment model alternative: A tiered matrix method (assessing risk levels based on probability of occurrence and impact matrix) can be used as a simplified alternative. Regardless of the model used, as long as it can prioritize threats, the purpose of risk assessment and ranking is achieved.

[0087] Deployment model variations: The system can run locally as a standalone application, or it can be deployed on a cloud platform as a SaaS service via a microservices architecture. The threat analysis engine can be deployed within a private network, while the 3D visualization interface can be deployed locally on the user's device, connected via a secure API.

[0088] Alternative to model collaboration: Threat model data can be synchronized to the team's DevOps collaboration tools or Wiki system for sharing among multiple teams, including development and security.

[0089] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for network security scenario modeling and threat analysis of dynamic embedded systems, characterized in that, Includes the following steps: Step S1, Scene Construction, wherein the scene construction is used to construct an embedded system business scene model and generate scene graph data; Step S2, dynamic simulation, the dynamic simulation is used to visualize the scene model and load threat rules; Step S3, Automatic Threat Identification, wherein the automatic threat identification is used to perform multi-strategy security analysis on assets in the scene, generate a threat list and construct attack paths or threat association graphs; Step S4, Threat Intelligence Association, which is used to match threat items with vulnerability intelligence data to enrich threat information; Step S5, Risk Rating and Model Improvement, is used to quantify and score threats and determine threat levels, and to improve the scenario model based on high-risk threats. Step S6, threat model visualization, which is used to overlay and visualize the threat analysis results and supports interactive viewing of threat details; Step S7, Report Generation and Export, wherein the report generation and export is used to automatically generate and export a security analysis report; Step S8, Model Management, which is used for centralized storage and collaborative management of scenario models and threat models.

2. The method according to claim 1, characterized in that: In step S1, embedded devices and network components are selected from the component library through a visual interface to construct a business scenario model of the target embedded system, configure node attributes, and generate scenario graph data that records node attributes and the connection relationships between nodes. The component library includes control boards, sensor nodes, bus lines, and communication gateways; The node attributes include hardware type, operating system, firmware version, network protocol, IP address, list of open ports, and security chip model.

3. The method according to claim 1, characterized in that: In step S2, the 3D rendering engine is activated to present the scene model in a 3D interactive visualization. Device nodes are displayed as models or icons, and nodes are connected by a link model. The system architecture can be viewed by rotating, panning, and zooming the view. The backend establishes a node topology graph and loads threat rules related to the scenario.

4. The method according to claim 1, characterized in that: In step S3, the STRIDE model is used to check the threat categories of the bus and communication modules. Known vulnerability pattern matching and attack tree analysis were performed on the firmware and operating system. Identify physical attack threats to security chips and hardware; The data flow graph and attack tree methods are used comprehensively for application software and communication protocols; The STRIDE model includes six major threat categories: identity impersonation, tampering, denial of responsibility, information leakage, denial of service, and privilege escalation. The physical attack threat identification includes JTAG interface abuse, malicious USB interface device attacks, side-channel attacks, and fault injection.

5. The method according to claim 1, characterized in that: In step S4, each threat item is matched and associated with the vulnerability intelligence database; The associated content includes vulnerability number, vulnerability name, public description, CVSS score, known exploit code, reference links, and historical attack cases; The vulnerability intelligence database includes a list of publicly available vulnerabilities, a library of known attack cases, and mitigation recommendations. It can be stored internally or connected to external intelligence sources via an API interface.

6. The method according to claim 1, characterized in that: In step S5, CVSS, DREAD, and OWASP risk scoring models are used for quantitative scoring, and the final threat level is determined by weighted average or by taking the most severe level. The CVSS score is calculated based on attack difficulty, impact range, and exploit complexity. The DREAD rating is based on five dimensions: severity of damage, reproducibility, availability, scope of affected users, and discoverability.

7. The method according to claim 1, characterized in that: In step S6, the threat analysis results are displayed in a three-dimensional overlay. The attack entry point is highlighted with a special color, high-risk devices are marked with a red warning symbol, medium-risk devices are marked with a yellow mark, and the attack path is displayed as a continuous arrow link. Users can click on the threat marker to view a detailed information panel.

8. A dynamic embedded system network security scenario modeling and threat analysis system, characterized in that: include: A scene modeling module, which is used to execute step S1; Threat analysis engine, which is used to perform step S3; Vulnerability intelligence database, which is used to provide intelligence data for step S4; Risk assessment module, which is used to perform step S5; A visualization rendering module, which is used to execute steps S2 and S6; The report generation and model management module is used to execute steps S7 and S8.

9. The system according to claim 8, characterized in that: The scene modeling module provides a graphical drag-and-drop modeling interface; The component library includes control boards, sensor nodes, bus lines, and communication gateway icons; The threat analysis engine integrates the STRIDE model, attack tree algorithm, data flow graph analysis, and OWASP security guidelines. The modules interact through a bus or API interface to form a complete threat modeling and analysis process.

10. The system according to claim 8, characterized in that: The system can operate as an independent software platform, or it can adopt a client / server architecture to separate the rendering interface from the backend analysis engine.

Images