Blockchain-based security log analysis method, device, equipment, medium and program product

Abstract

This application provides a blockchain-based security log analysis method, relating to the field of information security and applicable to the fintech sector. The method includes: pre-analyzing security logs to be uploaded to the blockchain to generate event tags, the event tags being used to provide risk alerts for suspicious behavior in the logs; adding timestamps to the pre-analyzed logs and performing digital signature operations to obtain target logs; invoking a smart contract based on the event tags to perform a risk assessment on the target logs to determine the risk assessment result; and storing the target logs and the risk assessment result on the blockchain. This application also provides a blockchain-based security log analysis device, equipment, storage medium, and program product.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, specifically to the field of information security technology, and more specifically to a blockchain-based security log analysis method, apparatus, device, medium, and program product. Background Technology

[0002] In today's highly information-driven world, cyberattacks are becoming increasingly sophisticated, and security incidents are frequent. To promptly detect security threats and trace the source of attacks, security logs have become an indispensable and crucial data foundation in network security systems. Various network devices and system components continuously generate large amounts of security logs to record critical operational behaviors, abnormal events, and communication processes. In actual operational environments, log data is often vulnerable to security threats such as tampering and deletion. Once attackers gain system control, they are highly likely to modify or delete logs to cover up intrusion traces, thereby hindering subsequent tracing and accountability. Furthermore, traditional log auditing mechanisms often employ centralized storage, which suffers from single points of failure, opaque access, and unreliable auditing, making it difficult to meet the requirements of high-security scenarios for log integrity and traceability. Summary of the Invention

[0003] In view of the above problems, this application provides a blockchain-based secure log analysis method, apparatus, device, medium and program product to improve log traceability.

[0004] According to the first aspect of this application, a blockchain-based security log analysis method is provided, comprising: pre-analyzing the security log to be uploaded to the blockchain to generate event tags, the event tags being used to provide risk warnings for suspicious behavior in the log; adding a timestamp to the pre-analyzed log and performing a digital signature operation to obtain a target log; invoking a smart contract based on the event tags to perform a risk assessment on the target log to determine a risk assessment result; and storing the target log and the risk assessment result on the blockchain.

[0005] According to an embodiment of this application, the pre-analysis of the security logs to be uploaded to the blockchain to generate event tags includes: constructing a behavioral profile based on the key fields of the security logs to be uploaded to the blockchain; matching the attack behavior characteristics of an attack pattern library based on the behavioral profile; and determining the event tags of the security logs to be uploaded to the blockchain according to preset tag rules and matching results.

[0006] According to an embodiment of this application, the smart contract has a built-in rule engine. The step of calling the smart contract based on the event tags to perform a risk assessment on the target log to determine the risk assessment result includes: parsing the event tags of the target log to match the rule subset corresponding to the smart contract; and parsing the target log fields according to the rule subset to determine the risk assessment result.

[0007] According to an embodiment of this application, the smart contract also has a pre-built lightweight machine learning model. The step of calling the smart contract based on the event tag to perform a risk assessment on the target log to determine the risk assessment result includes: extracting static features of the target log based on a predefined rule mapping table; calling an off-chain index service to obtain statistical features of the target log; inputting the static features and the statistical features into the lightweight machine learning model to output a risk score; and determining the risk assessment result based on the risk score.

[0008] According to an embodiment of this application, the method further includes: constructing an attack behavior association graph in response to the log data uplink operation; using a graph analysis algorithm to identify lateral attack paths in the attack behavior association graph; and visualizing the lateral attack paths based on a graph database.

[0009] According to an embodiment of this application, the step of constructing an attack behavior association graph in response to the on-chain operation of log data includes: extracting key entity information from the logs, wherein the key entity information includes user information, host information, process information, access time, operation type, risk level, and event tag; and constructing an attack behavior association graph with hosts, users, and processes as graph nodes and access relationships, control relationships, and command execution as edges.

[0010] According to embodiments of this application, the application graph analysis algorithm for attack path identification of the attack behavior association graph includes: identifying potential attack propagation paths based on a depth-first search algorithm; determining the fastest propagation path from the initial intrusion point to the critical target based on a shortest path algorithm; evaluating the influence of each node in the attack behavior association graph based on a page ranking algorithm to identify critical jump points or intermediate hosts; and using a community detection algorithm to identify attacker activity areas.

[0011] According to an embodiment of this application, storing the target log and the risk assessment result on the blockchain includes: calculating the digest hash of the target log; aggregating multiple log digests as a log batch using a hash tree structure to generate a root hash; and writing the root hash value into a target block of the blockchain, wherein the target block includes the root hash values ​​of multiple log batches and the hash value of the previous block.

[0012] A second aspect of this application provides a blockchain-based security log analysis device, comprising: a pre-analysis module for pre-analyzing security logs to be uploaded to the blockchain to generate event tags, the event tags being used to provide risk alerts for suspicious behavior in the logs; a target log generation module for adding timestamps to the pre-analyzed logs and performing digital signature operations to obtain target logs; a risk assessment module for invoking a smart contract based on the event tags to perform a risk assessment on the target logs to determine the risk assessment results; and an on-chain storage module for storing the target logs and the risk assessment results on the blockchain.

[0013] According to an embodiment of this application, the pre-analysis module includes a behavior profile construction submodule, a matching submodule, and a first determination submodule.

[0014] The profile construction submodule is used to construct a behavioral profile based on the key fields of the security log to be uploaded to the blockchain; the matching submodule is used to match the attack behavior characteristics of the attack pattern library based on the behavioral profile; and the first determination submodule is used to determine the event tags of the security log to be uploaded to the blockchain according to the preset tag rules and the matching results.

[0015] According to an embodiment of this application, the risk assessment module includes a first parsing submodule and a second parsing submodule.

[0016] The first parsing submodule is used to parse the event tags of the target log to match the rule subset corresponding to the smart contract; and the second parsing submodule is used to parse the target log fields according to the rule subset to determine the risk assessment result.

[0017] According to an embodiment of this application, the risk assessment module further includes: a static feature extraction submodule, a statistical feature acquisition submodule, an output submodule, and a second determination submodule.

[0018] The system includes a static feature extraction submodule for extracting static features from the target log based on a predefined rule mapping table; a statistical feature acquisition submodule for calling an off-chain index service to acquire statistical features from the target log; an output submodule for inputting the static features and the statistical features into the lightweight machine learning model to output a risk score; and a second determination submodule for determining the risk assessment result based on the risk score.

[0019] According to embodiments of this application, the apparatus further includes: a graph construction module, a graph analysis module, and a display module.

[0020] The graph construction module is used to construct an attack behavior association graph in response to the on-chain operation of log data; the graph analysis module is used to identify lateral attack paths in the attack behavior association graph using graph analysis algorithms; and the display module is used to visualize the lateral attack paths based on the graph database.

[0021] According to an embodiment of this application, the map construction module includes an entity information extraction submodule and a construction submodule.

[0022] The entity information extraction submodule is used to extract key entity information from the logs. The key entity information includes user information, host information, process information, access time, operation type, risk level, and event tag. The construction submodule is used to construct an attack behavior association graph with hosts, users, and processes as graph nodes and access relationships, control relationships, and command execution as edges.

[0023] According to an embodiment of this application, the graph analysis module includes a first identification submodule, a second identification submodule, a third identification submodule, and a fourth identification submodule.

[0024] The first identification submodule is used to identify potential attack propagation paths based on a depth-first search algorithm; the second identification submodule is used to determine the fastest propagation path from the initial intrusion point to the critical target based on a shortest path algorithm; the third identification submodule is used to evaluate the influence of each node in the attack behavior association graph based on a page ranking algorithm to identify key jump points or intermediate hosts; and the fourth identification submodule is used to identify the attacker's activity area using a community detection algorithm.

[0025] According to an embodiment of this application, the on-chain storage module includes a computation submodule, a generation submodule, and an on-chain submodule.

[0026] The calculation submodule is used to calculate the digest hash of the target log; the generation submodule is used to aggregate multiple log digests as a log batch and generate a root hash through a hash tree structure; the on-chain submodule is used to write the root hash value into the target block of the blockchain, the target block including the root hash values ​​of multiple log batches and the hash value of the previous block.

[0027] A third aspect of this application provides an electronic device comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0028] A fourth aspect of this application also provides a computer-readable storage medium having a computer program or instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0029] The fifth aspect of this application also provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0030] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0031] Figure 1 The illustration shows an application scenario of a blockchain-based security log analysis method, apparatus, device, medium, and program product according to embodiments of this application.

[0032] Figure 2 This illustration schematically shows an architecture diagram of a blockchain-based security log analysis system according to an embodiment of this application;

[0033] Figure 3 A flowchart illustrating a blockchain-based security log analysis method according to an embodiment of this application is shown schematically.

[0034] Figure 4 This illustration shows a flowchart of a method for storing target logs and risk assessment results on the blockchain according to an embodiment of this application;

[0035] Figure 5 A flowchart illustrating a lateral attack path identification method according to an embodiment of this application is shown schematically.

[0036] Figure 6 This schematically illustrates a structural block diagram of a blockchain-based security log analysis device according to an embodiment of this application; and

[0037] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a blockchain-based secure log analysis method according to an embodiment of this application. Detailed Implementation

[0038] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0039] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of the stated features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0040] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0041] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0042] This application provides a blockchain-based security log analysis method, comprising: pre-analyzing the security logs to be uploaded to the blockchain to generate event tags, the event tags being used to provide risk warnings for suspicious behavior in the logs; adding timestamps to the pre-analyzed logs and performing digital signature operations to obtain target logs; invoking a smart contract based on the event tags to perform risk assessment on the target logs to determine the risk assessment results; and storing the target logs and the risk assessment results on the blockchain.

[0043] Figure 1 The illustration shows an application scenario of a blockchain-based security log analysis method, apparatus, device, medium, and program product according to embodiments of this application.

[0044] like Figure 1 As shown, application scenario 100 according to this embodiment may include a security log analysis scenario. Network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. Network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0045] Users can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 via the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0046] The first terminal device 101, the second terminal device 102, and the third terminal device 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0047] Server 105 can be a server that provides various services, such as a backend management server that supports websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103 (this is just an example). The backend management server can analyze and process data such as received user requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices.

[0048] It should be noted that the blockchain-based security log analysis method provided in this application embodiment relates to the field of information security and can be used in the field of fintech. The blockchain-based security log analysis method provided in this application embodiment can generally be executed by server 105. Accordingly, the blockchain-based security log analysis device provided in this application embodiment can generally be set in server 105. The blockchain-based security log analysis method provided in this application embodiment can also be executed by a server or server cluster that is different from server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105. Accordingly, the blockchain-based security log analysis device provided in this application embodiment can also be set in a server or server cluster that is different from server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103, and / or server 105.

[0049] Figure 2 The illustration shows a schematic diagram of the architecture of a blockchain-based security log analysis system according to an embodiment of this application.

[0050] like Figure 2As shown, this security log analysis system includes a log preprocessing module, a blockchain log storage module, a smart contract verification and early warning module, and a lateral attack path construction and tracing module. The log collection terminal is responsible for collecting raw log data from various devices. The log preprocessing module performs format standardization, anonymization, and anomaly filtering on the collected logs. The preprocessed log data is then transmitted to the blockchain log storage module, which utilizes blockchain technology, block structure design, Merkle trees, and consensus mechanisms to ensure secure storage and immutability of the logs. Simultaneously, the smart contract verification and early warning module uses smart contracts to perform real-time verification and risk assessment of the logs. Its abnormal data alarm function triggers alerts when potential threats are detected, while its duplicate log identification function improves processing efficiency. The lateral attack path construction and tracing module transforms log data into an attack behavior correlation graph and uses graph algorithms to identify attack paths. Its visualization function allows security personnel to intuitively view attack paths and quickly formulate response strategies. Throughout the system architecture, the modules work closely together, with efficient and orderly information flow, jointly constructing a comprehensive and efficient log security protection and attack tracing system.

[0051] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0052] The following will be based on Figure 1 The scene described and Figure 2 The described system architecture, through Figures 3-5 A blockchain-based security log analysis method according to embodiments of this application will be described in detail.

[0053] Figure 3 A flowchart illustrating a blockchain-based security log analysis method according to an embodiment of this application is shown.

[0054] like Figure 3 As shown, the blockchain-based security log analysis method of this embodiment includes operations S210 to S240, which can be executed by a server or other computing device.

[0055] In operation S210, the security logs to be uploaded to the blockchain are pre-analyzed to generate event tags, which are used to provide risk alerts for suspicious behavior in the logs.

[0056] In operation S220, a timestamp is added to the pre-analyzed log, and a digital signature operation is performed to obtain the target log.

[0057] In operation S230, a smart contract is invoked based on the event tag to perform a risk assessment on the target log in order to determine the risk assessment result.

[0058] In operation S240, the target log and the risk assessment results are saved on the blockchain.

[0059] In one example, log collection nodes can be deployed on operating systems, firewalls, intrusion detection systems, intrusion prevention systems, web application firewalls, and databases, collecting logs in real time via interface protocols. The collected data includes user operation logs, network connection information, access control logs, process execution records, etc. After collection, data preprocessing operations are performed, including format standardization, anonymization, and anomaly filtering. The collected logs are first standardized in format: unifying timestamps, event types, source IPs, target IPs, user identifiers, and operation result fields; usernames, password attempts, and command parameters are anonymized using symmetric encryption hashing algorithms; and empty values, duplicates, and incorrectly formatted logs are removed using regular expressions.

[0060] In one example, the system extracts key fields, such as the number of failed login attempts, remote access frequency, privileged account usage, and cross-host connection counts. These are then lightweightly matched against a known attack pattern database to generate event tags such as "suspected brute-force attack," "high-risk command execution," "cross-host connection," and "privilege escalation." Priorities are set based on the severity of the event, determining whether to immediately trigger an alert or directly write it to a high-priority block.

[0061] In one example, each pre-processed and pre-analyzed log data is appended with a current timestamp and digitally signed using the device's private key for subsequent on-chain verification. Each log entry is timestamped, and the entire log content plus the timestamp is signed using a private key deployed on the collection node, generating a 64-byte digital signature.

[0062] In one example, when log data needs to be accessed or audited, this application also supports a rapid on-chain log location mechanism based on attack events. Specifically, the system maintains a lightweight index service to record key metadata of the logs (such as time range, IP address, user ID, event tag, etc.) and their corresponding on-chain locations (block number, transaction ID); it supports multi-dimensional conditional queries, such as: "Find all login behaviors involving IP 192.xxx.x.x0 between 12:00 and 12:10 on May 27, 2025"; "Retrieve logs with the 'abnormal login' tag within the past 24 hours whose source IP is not in the whitelist"; it quickly locates relevant blocks and transactions through the index service, avoiding full-chain scanning and significantly improving log retrieval efficiency; it also allows for correlation queries based on graph relationships, such as: "Find all subsequent redirect behaviors related to the initial entry point of a certain attack". Through the above design, not only is efficient collection and trusted encapsulation of log data achieved, but preliminary threat identification is also completed before being uploaded to the chain, and accurate and efficient log location capabilities are provided during the data retrieval stage, effectively supporting the subsequent attack path analysis and tracing work.

[0063] In one example, a blockchain node invokes a pre-deployed smart contract. The contract has a built-in rules engine and a lightweight machine learning model, which outputs the final risk level based on event tags and log fields. The contract writes the risk level, event tags, and log summary to the blockchain or consortium blockchain, and the block header retains the hash of the previous block and the consensus node's signature to ensure immutability.

[0064] The blockchain-based security log analysis method provided in this application pre-analyzes and generates event tags for security logs to be uploaded to the blockchain, enabling risk alerts for suspicious behaviors in the logs. This allows log data to possess preliminary risk identification capabilities before being uploaded to the blockchain. Simultaneously, adding timestamps and digital signatures to the pre-analyzed logs effectively prevents tampering during transmission and storage, ensuring the authenticity and integrity of the log data. Utilizing smart contracts to perform risk assessments on target logs and storing the assessment results along with the target logs on the blockchain not only automates risk assessment of log data but also leverages the immutability of blockchain to ensure the credibility and traceability of the assessment results, further enhancing log data security. This provides reliable technical support for log data traceability and auditing. Auditors can quickly locate and verify the authenticity and integrity of log data through the blockchain, thereby improving audit efficiency and accuracy.

[0065] According to an embodiment of this application, pre-analyzing the security logs to be uploaded to the blockchain to generate event tags includes: constructing a behavioral profile based on the key fields of the security logs to be uploaded to the blockchain; matching attack behavior characteristics of an attack pattern library based on the behavioral profile; and determining the event tags of the security logs to be uploaded to the blockchain according to preset tag rules and matching results.

[0066] In one example, key fields are first extracted from security logs. These fields include, but are not limited to, user actions, network connection details, access control results, and process execution status. For example, information such as the user's login account, login time, login IP address, and login status are extracted from the logs. A behavioral profile is then built based on these extracted key fields. For instance, by analyzing the distribution of a user's login time and the frequency of their login IP address over a period of time, a profile of the user's normal login behavior is constructed. If the time or IP address of a login action differs significantly from the normal behavioral profile, it may be considered abnormal behavior. The constructed behavioral profile is then matched against a pre-stored attack pattern library. This library contains characteristic descriptions of various known attack behaviors; for example, brute-force attacks typically manifest as a large number of failed login attempts within a short period, with the attempted passwords exhibiting a certain regularity. Event tags for the security logs to be uploaded to the blockchain are determined based on preset tagging rules and the matching results. For example, if the behavioral profile in the log matches a brute-force attack pattern, it is assigned the event tag "suspected brute-force"; if it matches a high-risk command execution attack pattern, it is assigned the event tag "high-risk command execution," and so on.

[0067] By extracting key fields to construct behavioral profiles and matching them with an attack pattern library to generate event tags, suspicious behaviors in logs can be effectively identified and risk alerts can be provided. This not only helps to provide early warnings of potential security threats before logs are uploaded to the blockchain, improving the timeliness and accuracy of security monitoring, but also provides more accurate basic data for subsequent log analysis and risk assessment, making the risk assessment results more reliable and thus enhancing the overall security protection capabilities of the system.

[0068] According to an embodiment of this application, the smart contract has a pre-built rule engine. The step of calling the smart contract based on the event tags to perform a risk assessment on the target log to determine the risk assessment result includes: parsing the event tags of the target log to match the rule subset corresponding to the smart contract; and parsing the target log fields according to the rule subset to determine the risk assessment result.

[0069] In one example, a smart contract deployed on the blockchain network performs format validation, signature verification, and threat prediction on each log record to be uploaded to the chain, ensuring the authenticity, integrity, and security of the log data. First, basic verification logic is executed to check if the log timestamp is within a reasonable window range to prevent rollback tampering; verify if the digital signature matches the public key of the data collection node; confirm if the log fields are complete and if the format conforms to the standard template; if any of the aforementioned conditions are not met, the log is rejected from being uploaded to the chain, and an audit event is generated.

[0070] In one example, after completing basic verification, the smart contract invokes the built-in rule engine and lightweight machine learning model to perform multi-dimensional analysis of the log content in a rule-first, model-later manner to identify potential security risks. Specifically, the smart contract parses the event tags carried by the target log and activates the corresponding rule subsets. For example, "suspected brute-force attack" triggers a brute-force attack rule, and "high-risk command execution" triggers a command audit rule. The rule engine executes according to the "field-threshold-action" triple: if the field value directly matches a high-confidence rule (such as "root + rm-rf / "), it immediately outputs a fixed risk level and skips subsequent modeling; if the field value falls into a fuzzy range, it outputs the rule confidence and initial weight as input features for the model.

[0071] In one example, the specific fields and judgment logic for risk analysis are shown in Table 1 below:

[0072] Table 1 Risk Analysis Log Fields and Judgment Logic

[0073]

[0074] According to an embodiment of this application, the smart contract also has a pre-built lightweight machine learning model. The step of calling the smart contract based on the event tag to perform a risk assessment on the target log to determine the risk assessment result includes: extracting static features of the target log based on a predefined rule mapping table; calling an off-chain index service to obtain statistical features of the target log; inputting the static features and the statistical features into the lightweight machine learning model to output a risk score; and determining the risk assessment result based on the risk score.

[0075] In one example, this application embodiment also uses a structured, configurable risk scoring system to convert log field information into specific sub-scores. The lightweight machine learning model is a scoring model trained on historical attack data. The sub-score for each dimension is automatically calculated by the smart contract based on a predefined rule mapping table and weight function, ensuring the transparency, consistency, and auditability of the scoring process. The predefined rule mapping tables are shown in Tables 2 to 6 below:

[0076] Table 2. Log Type Sensitivity Scoring Rules

[0077]

[0078] Table 3 User Permission Level Scoring Rules

[0079]

[0080] Table 4 Scoring Rules for the Degree of Time Anomalies

[0081]

[0082] Table 5 Geographical Location Risk Scoring Rules

[0083]

[0084] Table 6. Scoring Rules for Behavioral Association Features

[0085]

[0086] In one example, the weight coefficients for the five core evaluation dimensions corresponding to Tables 2-6 are: Log Type Sensitivity 0.2, User Permission Level 0.2, Time Anomaly Level 0.15, Geographic Location Risk 0.15, and Behavioral Association Feature 0.3. When a log entry enters the smart contract, its field values ​​are matched item by item against the predefined rule mapping table, mapping the log fields to 5 static features: Log Type Sensitivity, User Permission Level, Time Anomaly Level, Geographic Location Risk, and Behavioral Association Feature, with each dimension normalized to [0,1]. The off-chain index service aggregates logs from the same user / IP within the last 24 hours, generating: Failed Login Count, Cross-Host Connection Frequency, Command Entropy Value, and Percentage of Operations During Abnormal Periods, forming a 25-dimensional statistical feature. The 30-dimensional feature vector is input into the contract's built-in scoring model to obtain the corresponding sub-score values. The system calculates a comprehensive risk score based on a pre-set rule set and scoring model, and finally maps it to one of four risk levels: Low (0.0, 0.3), Medium (0.3, 0.6), High (0.6, 0.85), and Critical (0.85, 1.0). High-risk levels indicate high-risk behavior, potentially posing a security threat, requiring initial response measures. Critical levels indicate extremely suspicious behavior, highly likely an attack, requiring immediate alerts and triggering a deep investigation process.

[0087] In one example, to improve the system's flexibility and adaptability, all rule mapping tables and weight parameters can be updated through the management node or smart contract interface without requiring downtime maintenance. When performing a risk assessment on a target log labeled "high-risk command execution": First, static features of the target log, such as command type and execution time, are extracted based on a predefined rule mapping table. Then, an off-chain index service is called to obtain the target log's statistical features, such as the command's execution frequency over the past week and the typical privilege level of the user executing the command. These static and statistical features are input into a lightweight machine learning model. Based on the patterns and rules obtained during training, the model outputs a risk score, for example, 0.84. Based on this risk score, the risk assessment result for the target log is determined to be "High" risk level.

[0088] In one example, when a log is marked as high-risk or critical-risk, the smart contract automatically triggers an alert event, notifying the security management platform or SIEM system. It supports multiple response strategies, such as real-time alert push notifications, initiating a deep log analysis process, and adding relevant logs to a priority retrieval queue for rapid subsequent location and correlation analysis. For instance, if the log content shows multiple consecutive failed SSH logins (user root, source IP address overseas), the smart contract determines it as "suspected brute-force attack," sets the risk level to High, labels it "BruteForceAttempt," and triggers an alert. Simultaneously, the log ID and its associated block information are written to the indexing service for rapid retrieval during subsequent attack path analysis.

[0089] Figure 4 The flowchart illustrates a method for storing target logs and risk assessment results on the blockchain according to an embodiment of this application.

[0090] like Figure 4 As shown, this includes operations S410 to S430.

[0091] In operation S410, the digest hash of the target log is calculated.

[0092] When operating S420, multiple log summaries are treated as a log batch and aggregated using a hash tree structure to generate a root hash.

[0093] In operation S430, the root hash value is written into the target block of the blockchain, the target block including the root hash values ​​of multiple log batches and the hash value of the previous block.

[0094] In one example, to address the data redundancy and performance bottleneck issues caused by "full on-chaining of raw logs" in related technologies, this application adopts a digest-on-chain mechanism. Each preprocessed and signed log is not directly uploaded to the chain, but its hash digest (such as SHA-256 or SM3) is calculated first. The digests of multiple logs are combined into a log batch, and a root hash is generated by aggregating them through a Merkle tree structure. Only the Merkle root hash value is written into the block to achieve unified notarization of multiple log records. The raw log data and its complete Merkle tree structure are stored in off-chain trusted storage, and a mapping relationship is established with on-chain information through an index service.

[0095] In one example, each block contains Merkle root hashes of multiple log batches, as well as the hash value of the previous block, forming a chain structure. The block header retains metadata such as timestamps and consensus node signatures for subsequent auditing and tracing. A light node verification mode is supported, meaning basic time sequence and integrity verification can be completed simply by downloading the block header. When verifying a specific log entry, the system locates its batch and Merkle path based on its unique identifier (such as log ID or event time); it retrieves the original log and corresponding Merkle path proof from off-chain, and performs consistency verification by combining it with the on-chain Merkle root hash; successful verification proves that the log has not been tampered with since its collection and has been successfully stored on-chain. Dedicated smart contracts are deployed to manage log batch indexes, Merkle root hash records, and access control policies; on-chain fast queries based on event tags, time ranges, IP addresses, etc., are supported; and a log validity verification interface is provided for third-party auditing or evidence collection systems to call.

[0096] In one example, assuming 100 log entries are collected every 10 seconds, the system first calculates the hash of each entry, constructs a Merkle tree to obtain the root hash value, and writes this root hash value into a block. The raw log data is stored in encrypted form off-chain and indexed by log ID and block location. When verifying the 53rd log entry, the system returns the original content of the log entry, the Merkle path, and the root hash value in the corresponding block. Users can then verify its authenticity using a local verification algorithm.

[0097] Figure 5 A flowchart illustrating a lateral attack path identification method according to an embodiment of this application is shown.

[0098] like Figure 5 As shown, it includes operation S510 and operation S520.

[0099] When operating the S510, in response to the on-chain operation of log data, an attack behavior correlation graph is constructed.

[0100] In operation S520, a graph analysis algorithm is used to identify lateral attack paths in the attack behavior association graph.

[0101] According to an embodiment of this application, in response to the on-chain operation of log data, constructing an attack behavior association graph includes: extracting key entity information from the logs, the key entity information including user information, host information, process information, access time, operation type, risk level, and event tag; and constructing an attack behavior association graph with hosts, users, and processes as graph nodes and access relationships, control relationships, and command execution as edges.

[0102] In one example, a graph construction task is initiated immediately after a new block is written. Specifically, key entity information is extracted from the logs, including user information (e.g., user ID, username); host information (e.g., host IP, hostname); process information (e.g., process ID, process name); operation type (e.g., login, file access, command execution); risk level (e.g., low risk, medium risk, high risk); and event tags (e.g., "suspected brute-force attack," "high-risk command execution"). An attack behavior association graph is constructed using hosts, users, and processes as graph nodes, and access relationships, control relationships, and command execution as edges. Access relationships include, for example, a user accessing a host, or a process accessing a file; control relationships include, for example, a user controlling a process, or a host controlling other hosts; and command execution includes, for example, a process executing a command, or a user executing a command. When a user logs in from host A to host B and executes a high-risk command, the graph will generate a node representing that user, a node representing host A, and a node representing host B, as well as edges representing login and command execution.

[0103] According to embodiments of this application, the application graph analysis algorithm for attack path identification of the attack behavior association graph includes: identifying potential attack propagation paths based on a depth-first search algorithm; determining the fastest propagation path from the initial intrusion point to the critical target based on a shortest path algorithm; evaluating the influence of each node in the attack behavior association graph based on a page ranking algorithm to identify critical jump points or intermediate hosts; and using a community detection algorithm to identify attacker activity areas.

[0104] In one example, a depth-first search algorithm is used to identify potential attack propagation paths. Starting from the initial intrusion point, the search delves deeper along the edges of the graph until the target node is found or further exploration is impossible, thus discovering the attacker's possible attack routes. For example, if an attacker penetrates the internal network from an external host A, sequentially logs into host X via Secure Shell (SSH), connects to host Y using Remote Desktop Protocol (RDP), and uploads malicious files to host Z via Server Message Block (SMB), the depth-first search algorithm can identify this complete attack path.

[0105] In one example, the shortest path algorithm is used to determine the fastest propagation path from the initial intrusion point to the critical target. The algorithm calculates the shortest paths between nodes in the network graph to find the fastest attack route for the attacker from the initial point to the target. For instance, in a complex network, there may be multiple paths from the attacker's initial location to the critical server; the shortest path algorithm can find the path with the shortest time or lowest risk.

[0106] In one example, a PageRank algorithm is used to assess the influence of each node in the attack behavior correlation graph to identify key jump points or intermediate hosts. The importance of a node in the network is determined by calculating its PageRank value. For example, in the attack behavior correlation graph, a host node with a high PageRank value indicates that it may be accessed or controlled by multiple other hosts, or that it controls multiple other hosts, making it a key node in the attack propagation. Community detection algorithms are used to identify attacker activity areas. The attack behavior correlation graph is divided into different communities, with high connection density between nodes within each community and low connection density between communities. For example, the Louvain algorithm can identify the network areas where attackers are primarily active, helping security personnel focus their efforts on protecting these areas.

[0107] Based on the aforementioned blockchain-based security log analysis method, this application also provides a blockchain-based security log analysis device. The following will combine... Figure 6 The device is described in detail.

[0108] Figure 6 A schematic diagram of a blockchain-based security log analysis device according to an embodiment of this application is shown.

[0109] like Figure 6As shown, the blockchain-based security log analysis device 600 of this embodiment includes a pre-analysis module 610, a target log generation module 620, a risk assessment module 630, and an on-chain storage module 640.

[0110] The pre-analysis module 610 is used to pre-analyze the security logs to be uploaded to the blockchain to generate event tags. These event tags are used to provide risk alerts for suspicious behavior in the logs. In one embodiment, the pre-analysis module 610 can be used to perform the operation S210 described above, which will not be repeated here.

[0111] The target log generation module 620 is used to add timestamps to the pre-analyzed logs and perform digital signature operations to obtain the target logs. In one embodiment, the target log generation module 620 can be used to perform the operation S220 described above, which will not be repeated here.

[0112] The risk assessment module 630 is used to invoke a smart contract based on the event tag to perform a risk assessment on the target log, in order to determine the risk assessment result. In one embodiment, the risk assessment module 630 can be used to perform the operation S230 described above, which will not be repeated here.

[0113] The on-chain storage module 640 is used to save the target log and the risk assessment results on the blockchain. In one embodiment, the on-chain storage module 640 can be used to perform the operation S240 described above, which will not be repeated here.

[0114] According to an embodiment of this application, the pre-analysis module includes a behavior profile construction submodule, a matching submodule, and a first determination submodule.

[0115] The profile construction submodule is used to construct a behavioral profile based on the key fields of the security log to be uploaded to the blockchain; the matching submodule is used to match the attack behavior characteristics of the attack pattern library based on the behavioral profile; and the first determination submodule is used to determine the event tags of the security log to be uploaded to the blockchain according to the preset tag rules and the matching results.

[0116] According to an embodiment of this application, the risk assessment module includes a first parsing submodule and a second parsing submodule.

[0117] The first parsing submodule is used to parse the event tags of the target log to match the rule subset corresponding to the smart contract; and the second parsing submodule is used to parse the target log fields according to the rule subset to determine the risk assessment result.

[0118] According to an embodiment of this application, the risk assessment module further includes: a static feature extraction submodule, a statistical feature acquisition submodule, an output submodule, and a second determination submodule.

[0119] The system includes a static feature extraction submodule for extracting static features from the target log based on a predefined rule mapping table; a statistical feature acquisition submodule for calling an off-chain index service to acquire statistical features from the target log; an output submodule for inputting the static features and the statistical features into the lightweight machine learning model to output a risk score; and a second determination submodule for determining the risk assessment result based on the risk score.

[0120] According to embodiments of this application, the apparatus further includes: a graph construction module, a graph analysis module, and a display module.

[0121] The graph construction module is used to construct an attack behavior association graph in response to the on-chain operation of log data; the graph analysis module is used to identify lateral attack paths in the attack behavior association graph using graph analysis algorithms; and the display module is used to visualize the lateral attack paths based on the graph database.

[0122] According to an embodiment of this application, the map construction module includes an entity information extraction submodule and a construction submodule.

[0123] The entity information extraction submodule is used to extract key entity information from the logs. The key entity information includes user information, host information, process information, access time, operation type, risk level, and event tag. The construction submodule is used to construct an attack behavior association graph with hosts, users, and processes as graph nodes and access relationships, control relationships, and command execution as edges.

[0124] According to an embodiment of this application, the graph analysis module includes a first identification submodule, a second identification submodule, a third identification submodule, and a fourth identification submodule.

[0125] The first identification submodule is used to identify potential attack propagation paths based on a depth-first search algorithm; the second identification submodule is used to determine the fastest propagation path from the initial intrusion point to the critical target based on a shortest path algorithm; the third identification submodule is used to evaluate the influence of each node in the attack behavior association graph based on a page ranking algorithm to identify key jump points or intermediate hosts; and the fourth identification submodule is used to identify the attacker's activity area using a community detection algorithm.

[0126] According to an embodiment of this application, the on-chain storage module includes a computation submodule, a generation submodule, and an on-chain submodule.

[0127] The calculation submodule is used to calculate the digest hash of the target log; the generation submodule is used to aggregate multiple log digests as a log batch and generate a root hash through a hash tree structure; the on-chain submodule is used to write the root hash value into the target block of the blockchain, the target block including the root hash values ​​of multiple log batches and the hash value of the previous block.

[0128] According to embodiments of this application, any multiple modules among the pre-analysis module 610, target log generation module 620, risk assessment module 630, and on-chain storage module 640 can be merged into one module, or any one of these modules can be split into multiple modules. Alternatively, at least some of the functions of one or more of these modules can be combined with at least some of the functions of other modules and implemented in one module. According to embodiments of this application, at least one of the pre-analysis module 610, target log generation module 620, risk assessment module 630, and on-chain storage module 640 can be at least partially implemented as hardware circuitry, such as a field-programmable gate array (FPGA), a programmable logic array (PLA), a system-on-a-chip, a system-on-a-substrate, a system-on-package, an application-specific integrated circuit (ASIC), or any other reasonable means of integrating or packaging circuitry, or implemented in software, hardware, or firmware, or in any suitable combination of any of these three implementation methods. Alternatively, at least one of the pre-analysis module 610, the target log generation module 620, the risk assessment module 630, and the on-chain storage module 640 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0129] Figure 7 A block diagram schematically illustrates an electronic device suitable for implementing a blockchain-based secure log analysis method according to an embodiment of this application.

[0130] like Figure 7 As shown, an electronic device 700 according to an embodiment of this application includes a processor 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage portion 708 into a random access memory (RAM) 703. The processor 701 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or an associated chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 701 may also include onboard memory for caching purposes. The processor 701 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of this application.

[0131] RAM 703 stores various programs and data required for the operation of electronic device 700. Processor 701, ROM 702, and RAM 703 are interconnected via bus 704. Processor 701 executes various operations of the method flow according to embodiments of this application by executing programs in ROM 702 and / or RAM 703. It should be noted that the programs may also be stored in one or more memories other than ROM 702 and RAM 703. Processor 701 may also execute various operations of the method flow according to embodiments of this application by executing programs stored in said one or more memories.

[0132] According to embodiments of this application, the electronic device 700 may further include an input / output (I / O) interface 705, which is also connected to a bus 704. The electronic device 700 may also include one or more of the following components connected to the input / output (I / O) interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output (I / O) interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0133] This application also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0134] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include ROM 702 and / or RAM 703 and / or one or more memories other than ROM 702 and RAM 703 described above.

[0135] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code enables the computer system to implement the blockchain-based secure log analysis method provided in the embodiments of this application.

[0136] When the computer program is executed by the processor 701, it performs the functions defined in the system / apparatus of this application embodiment. According to the embodiments of this application, the systems, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0137] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and may be downloaded and installed via the communication section 709, and / or installed from a removable medium 711. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0138] In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from the removable medium 711. When the computer program is executed by the processor 701, it performs the functions defined in the system of this application embodiment. According to the embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0139] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, languages ​​such as Java, C++, Python, "C", or similar programming languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0140] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0141] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A blockchain-based security log analysis method, characterized in that, The method includes: The security logs to be uploaded to the blockchain are pre-analyzed to generate event tags, which are used to provide risk alerts for suspicious behavior in the logs. Add timestamps to the pre-analyzed logs and perform digital signature operations to obtain the target logs; Based on the event tag, a smart contract is invoked to perform a risk assessment on the target log, in order to determine the risk assessment result; and The target log and the risk assessment results are stored on the blockchain.

2. The method according to claim 1, characterized in that, The pre-analysis of the security logs to be uploaded to the blockchain to generate event tags includes: A behavioral profile is constructed based on the key fields of the security log to be uploaded to the blockchain. Attack behavior characteristics are matched based on the attack pattern library of the aforementioned behavioral profiles; and The event tags for the security logs to be uploaded to the blockchain are determined based on preset tagging rules and matching results.

3. The method according to claim 1, characterized in that, The smart contract has a pre-built rule engine. The step of invoking the smart contract based on the event tag to perform a risk assessment on the target log, and to determine the risk assessment result, includes: Parse the event tags of the target log to match the rule subset corresponding to the smart contract; and The target log fields are parsed based on the subset of rules to determine the risk assessment results.

4. The method according to claim 1, characterized in that, The smart contract also has a pre-built lightweight machine learning model. The step of calling the smart contract based on the event tag to perform a risk assessment on the target log, and determining the risk assessment result, includes: Extract static features from target logs based on a predefined rule mapping table; Call the off-chain index service to obtain the statistical characteristics of the target log; The static features and statistical features are input into the lightweight machine learning model to output a risk score; and The risk assessment result is determined based on the risk score.

5. The method according to claim 1, characterized in that, The method further includes: In response to the on-chain operation of log data, construct an attack behavior correlation graph; The attack behavior association graph is analyzed using graph analysis algorithms to identify lateral attack paths; and Visualize lateral attack paths using graph databases.

6. The method according to claim 5, characterized in that, The process of constructing an attack behavior correlation graph in response to the uplink operation of log data includes: Extract key entity information from the logs, including user information, host information, process information, access time, operation type, risk level, and event tag; and Using hosts, users, and processes as graph nodes, and access relationships, control relationships, and command execution as edges, an attack behavior association graph is constructed.

7. The method according to claim 5, characterized in that, The application graph analysis algorithm identifies attack paths in the attack behavior association graph, including: Identifying potential attack propagation paths using a depth-first search algorithm; The shortest path algorithm is used to determine the fastest propagation path from the initial invasion point to the critical target. The influence of each node in the attack behavior correlation graph is evaluated based on the page ranking algorithm to identify key jump points or intermediate hosts; and Community detection algorithms are used to identify areas of attacker activity.

8. The method according to any one of claims 1 to 7, characterized in that, The step of saving the target log and the risk assessment results on the blockchain includes: Calculate the digest hash of the target log; Multiple log summaries are treated as a log batch and aggregated using a hash tree structure to generate a root hash. The root hash value is written into the target block of the blockchain, the target block including the root hash values ​​of multiple log batches and the hash value of the previous block.

9. A blockchain-based security log analysis device, characterized in that, The device includes: The pre-analysis module is used to pre-analyze the security logs to be uploaded to the blockchain to generate event tags, which are used to provide risk alerts for suspicious behavior in the logs. The target log generation module is used to add timestamps to the pre-analyzed logs and perform digital signature operations to obtain the target logs; The risk assessment module is used to invoke a smart contract based on the event tag to perform a risk assessment on the target log, in order to determine the risk assessment result; and The on-chain storage module is used to save the target logs and the risk assessment results on the blockchain.

10. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 8.

11. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 8.

Images