Block chain-based security alarm data trusted storage method and system

Abstract

The invention provides a trusted storage method and system for security alarm data based on a block chain. The method comprises the following steps: analyzing alarm events from different sources and mapping the alarm events into structured alarm data; packaging the structured alarm data into an SQL write-in transaction, and constructing rwT metadata with a transaction triple in combination with addition, deletion, modification and check operations of the alarm data; performing consensus processing on the rwT metadata by using an EOV model; writing the data subjected to the consensus verification into an SQL enhanced block chain; and completing query analysis of alarm events of different sources in the SQL enhanced block chain. According to the block chain storage architecture based on the relational database, an SQL structured storage mode is adopted, compared with a Key-Value storage mode of a traditional block chain, the data query efficiency, the access speed and the multi-table joint query capability are improved, and alarm data can be managed more efficiently. Through an EOV transaction management mechanism, the sequence consistency of transactions is ensured, concurrent conflicts are prevented, and the consistency and integrity of data are improved.

Description

Technical Field

[0001] The present invention relates to the fields of blockchain technology and network security technology, and particularly to a method and system for securely storing alarm data based on blockchain. Background Art

[0002] Blockchain is a decentralized and distributed storage technology with characteristics such as data immutability, transparency and traceability, and consensus verification. It is commonly used in distributed data storage, transaction processing, and multi-party collaboration scenarios. In the modern network security system, various security detection systems (such as intrusion detection system IDS, security information and event management SIEM) will generate a large amount of alarm data during the process of detecting and scanning attacks, SQL injection, privilege escalation, data theft and other attack behaviors. Alarm data generally contains key information such as the source of the attack, the target, the type of attack, the timestamp, and the event priority. These information play an important role in analyzing network attack behaviors, constructing attack chains, detecting advanced persistent threats (APT), and improving the network security situation awareness ability.

[0003] Existing security alarm data storage and analysis systems mainly manage data based on centralized databases (SQL or NoSQL). This method has problems such as high risk of data tampering, difficult data sharing, low query efficiency, difficulty in ensuring data consistency, and insufficient attack chain analysis ability. In particular, due to the centralized storage mode of the centralized database, after an attacker successfully invades the system, they may tamper with or delete log data, affecting the tracking and evidence collection of security incidents. In addition, existing systems are difficult to support cross-organization threat intelligence sharing, easily resulting in detection islands. To effectively identify potential attack patterns, discover abnormal activities, and improve the overall security defense ability, it is necessary to design a system that can efficiently store and query security alarm data, and then achieve the aggregation and analysis of multi-source alarm data. Summary of the Invention

[0004] In order to overcome the deficiencies of the prior art, the purpose of the present invention is to provide a security alarm data storage and analysis system and method with high query efficiency, strong transaction consistency, and excellent scalability, so as to solve the problems of low data access and storage efficiency, insufficient transaction consistency, and weak multi-step attack chain analysis ability existing in the existing blockchain storage solutions, and improve the data access speed, attack pattern detection ability, and traceability of security alarm data.

[0005] To achieve the above purpose, the present invention provides the following solutions:

[0006] A method for securely storing alarm data based on blockchain, comprising:

[0007] Step 1: Collect alarm events from network security management systems of different sources;

[0008] Step 2: Parse the alarm events from different sources and map them to structured alarm data;

[0009] Step 3: Package the structured alarm data into an SQL write transaction, and construct rwT metadata with transaction triples in combination with the create, read, update, and delete operations of the alarm data; the rwT metadata includes the primary key rowKey of the alarm data record, the operation type Operation, the changed content AfterImage, and the custom extension field attr; among them, the attr field allows developers to attach business label information to each transaction;

[0010] Step 4: Use the Execute-Order-Validate model to perform consensus processing on the rwT metadata;

[0011] Step 5: Write the data after consensus verification into the SQL enhanced blockchain;

[0012] Step 6: Complete the query analysis of alarm events from different sources in the SQL enhanced blockchain.

[0013] Preferably, the Step 2: Parse the alarm events from different sources and map them to structured alarm data, includes:

[0014] Parse the alarm events from different sources to form alarm records;

[0015] Extract key fields from the alarm records;

[0016] Uniformly map the extracted key fields to a predefined standard field structure;

[0017] Perform standardization and legality cleaning on the predefined standard field structure to form structured alarm data.

[0018] Preferably, the Step 3: Package the structured alarm data into an SQL write transaction, and construct rwT metadata with transaction triples in combination with the create, read, update, and delete operations of the alarm data;

[0019] Package the structured alarm data into an SQL write transaction to form an SQL transaction;

[0020] Convert the SQL transaction into a read-only SELECT query, which is simulated and executed by the Peer node to generate the expected data content WriteSet to be written or modified by the transaction, the read data records and their versions ReadSet;

[0021] Construct rwT metadata with transaction triples in combination with the expected data content WriteSet to be written or modified by the transaction, the read data records and version information ReadSet, and the create, read, update, and delete operations of the alarm data.

[0022] Preferably, in step 4: using the Execute-Order-Validate model to perform consensus processing on the rwT metadata, including:

[0023] In the Execute phase, the client submits the constructed SQL transaction to the chaincode interface;

[0024] After receiving the proposal, the Peer node converts the SQL statement into a corresponding read-only SQL query, generates the ReadSet and WriteSet of the transaction, and encapsulates the rwT metadata of the transaction together with the read-write set into a proposal response and generates the corresponding endorsement signature;

[0025] In the Order phase, after the client collects a preset number of endorsement signatures, it constructs a final transaction proposal and submits the final transaction proposal to the Orderer service node;

[0026] The Orderer service node globally sorts the final transaction proposals in the order of submission to form a block structure:

[0027]

[0028] The sorted block is broadcast to all Peer nodes and enters the Validate phase;

[0029] In the Validate phase, each Peer node sequentially performs version verification on the transactions in the block, checking whether the version information recorded in the ReadSet of each transaction is consistent with the current on-chain state;

[0030] Extract all the transactions that pass the version verification, calculate the hash digest tx_hash of the transaction, and write it into the tx_hash field in the rw_transaction table as the data after consensus verification.

[0031] Preferably, in step 5: writing the data after consensus verification into the SQL enhanced blockchain, including:

[0032] Write the alarm data into the alerts table for querying, visual display, and trend analysis of the alarms;

[0033] Write the transaction triple rwT into the rw_transaction table and record the version information in the history_table to enable time playback, data difference comparison, and status tracking based on the transaction version;

[0034] Aggregate all the transaction hash values included in each block to construct a Merkle tree, and write the root hash merkle_root, block hash block_hash, and block meta-information into the block_table for verifying whether any transaction has been tampered with.

[0035] The present invention also provides a secure alarm data storage system based on a blockchain, including:

[0036] An alarm event collection module for collecting alarm events from network security management systems of different sources;

[0037] A structuring module for parsing alarm events from different sources and mapping them into structured alarm data;

[0038] An SQL transaction construction module for encapsulating structured alarm data into SQL-written transactions and constructing rwT metadata with transaction triples in combination with the create, delete, update, and query operations of the alarm data; the rwT metadata includes the primary key rowKey of the alarm data record, the operation type Operation, the changed content AfterImage, and a custom extension field attr; wherein, the attr field allows developers to attach business label information to each transaction;

[0039] A consensus processing module for performing consensus processing on the rwT metadata using the Execute-Order-Validate model;

[0040] A transaction writing module for writing the data verified by consensus into an SQL-enhanced blockchain;

[0041] A query and analysis module for completing the query and analysis of alarm events from different sources in the SQL-enhanced blockchain.

[0042] The present invention also provides an electronic device, including a bus, a transceiver, a memory, a processor, and a computer program stored on the memory and executable on the processor. The transceiver, the memory, and the processor are connected through the bus. It is characterized in that when the computer program is executed by the processor, the steps in the above-mentioned method for securely storing trusted alarm data based on a blockchain are implemented.

[0043] The present invention also provides a computer-readable storage medium, on which a computer program is stored. It is characterized in that when the computer program is executed by a processor, the steps in the above-mentioned method for securely storing trusted alarm data based on a blockchain are implemented.

[0044] The beneficial effects of a method for securely storing alarm data based on blockchain provided by the present invention are as follows: Compared with the prior art, the blockchain storage architecture based on a relational database in the present invention adopts an SQL structured storage method, which improves the data query efficiency, access speed, and multi-table joint query ability compared with the Key-Value storage method of traditional blockchains, and helps to manage alarm data more efficiently. Through the EOV (Execute-Order-Validate) transaction management mechanism, the sequential consistency of transactions is ensured, concurrent conflicts are prevented, and the consistency and integrity of data are improved.

[0045] In addition, the present invention combines SQL query optimization techniques, adopts index optimization and SQL aggregation analysis, supports efficient query of specific attack patterns, can quickly respond to the security alarm query requirements, and helps to improve the performance of network threat detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0047] Figure 1 is a method for securely storing alarm data based on blockchain provided by an embodiment of the present invention;

[0048] Figure 2 is a schematic diagram of a blockchain security alarm data storage device provided by an embodiment of the present invention;

[0049] Figure 3 is a schematic diagram of the transaction consensus structure of a blockchain security alarm data storage and analysis system provided by an embodiment of the present invention;

[0050] Figure 4 is a structural diagram of an SQL enhanced blockchain framework provided by an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0051] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0052] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments can be included in at least one embodiment of the present application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0053] The terms "first", "second", "third", "fourth", etc. in the specification, claims, and drawings of the present application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a series of steps, processes, methods, etc. included do not limit to the listed steps, but optionally further include steps not listed, or optionally further include other step elements inherent to these processes, methods, products, or devices.

[0054] To make the above objects, features, and advantages of the present invention more obvious and understandable, the present invention will be further described in detail below with reference to the drawings and specific embodiments.

[0055] The object of the present invention is to provide a secure alarm data storage and analysis system and method with high query efficiency, strong transaction consistency, and excellent scalability, so as to solve the problems of low data access and storage efficiency, insufficient transaction consistency, and weak multi-step attack chain analysis ability in existing blockchain storage solutions, and improve the data access speed, attack mode detection ability, and traceability of security alarm data.

[0056] Please refer to Figure 1 , a method for securely storing trusted alarm data based on blockchain, including:

[0057] Step 1: Collect alarm events from network security management systems of different sources;

[0058] In Step 1, first, real-time streaming collection of alarm data from intrusion detection systems (IDS) and security information and event management systems (SIEM) is achieved through a Kafka proxy, and it is pushed to the data processing system; then, log collection tools such as Fluentd or Logstash are used to parse and format the original log data, and uniformly convert it into a structured standard format; at the same time, the system will also regularly extract various types of original log data such as Web access logs, mail server logs, and DNS resolution records from the log storage server, and combine attack recognition tags to further generate structured alarm events for on-chain processing.

[0059] Step 2: Parse alarm events from different sources and map them to structured alarm data;

[0060] Structure standardization and field mapping include the following steps:

[0061] In the data structure standardization stage, the system first parses and processes alarm logs from different sources. According to the format specifications of different log sources (such as JSON, CSV, syslog, etc.), using Fluentd, Logstash or ETL tools, etc., it parses alarm records one by one, and accurately extracts key fields from them, such as event identifier, source IP, destination IP, alarm level, alarm time, event description, etc.;

[0062] Subsequently, the system uniformly maps the extracted fields to a set of predefined standard field structures to ensure the consistency of all alarm data at the semantic layer, as shown in Table 1 below:

[0063] Table 1: Common field mapping relationships

[0064]

[0065] After the system extracts the fields, it will automatically identify the positions of the above fields in the original data, and standardize them into a unified data structure through a field mapping table or conversion script; the unrecognized fields will be classified into the extended_info extended field for subsequent further processing or compatibility with new formats;

[0066] After completing the field mapping, the system will perform type standardization and legal cleaning on each field. The timestamp field is uniformly converted to the ISO 8601 standard format (YYYY-MM-DD HH:MM:SS), the IP address is checked for syntax and format, and the alarm severity field is also uniformly converted to standard classifications such as HIGH, MEDIUM, LOW, etc.; at the same time, the system will clear redundant information and invalid fields to keep the data concise;

[0067] For the case of missing fields, the system will perform automatic completion: if the time information is missing, the collection time will be used as the default value; if the alarm level is not specified, it will be marked as UNKNOWN; if the event description is missing, the system will generate a default prompt according to the source or rules to ensure the integrity of each alarm record structure;

[0068] After completing the above processing, the system generates a standardized structured data format, usually the data rows corresponding to the SQL table structure, and can also be exported as an equivalent JSON object for use as the input for subsequent SQL transaction construction.

[0069] Step 3: Package the structured alarm data into SQL and write it into a transaction, and construct the rwT metadata with transaction triples in combination with the create, delete, update, and query operations of the alarm data; the rwT metadata includes the primary key rowKey of the alarm data record, the operation type Operation, the changed content AfterImage, and the custom extension field attr; among them, the attr field allows developers to attach business label information to each transaction.

[0070] In Step 3, after data standardization is completed, the system packages each piece of structured alarm data into SQL and writes it into a transaction, and synchronously constructs an associated rwT (Read-Write Transaction) structure; this operation not only constitutes the logical unit of on-chain data changes but also provides the core basis for subsequent audit analysis.

[0071] First, the system converts the alarm data into a standard SQL write statement, such as:

[0072] INSERT INTO alerts(

[0073] alert_id,src_ip,dst_ip,severity,attack_type,

[0074] description,timestamp,status

[0075] )VALUES(

[0076] 'AL1234','192.168.1.10','10.0.0.1','HIGH','SQL Injection',

[0077] 'Detected malicious query','2025-03-24 12:03:01','UNRESOLVED' );

[0079] This transaction will not be executed immediately but will first be converted into a read-only SELECT query in the chain code, for example:

[0080] SELECT * FROM alerts WHERE alert_id = 'AL1234';

[0081] This query is simulated and executed by Peer nodes to generate the ReadSet (the data records read and their versions) and WriteSet (the data content expected to be written or modified) for this transaction. These two sets together constitute the "scope of influence" of this transaction, which is used for subsequent consistency verification; on this basis, the system constructs an rwT triple structure to represent the change operation performed on a single piece of data (identified by rowKey), including:

[0082] rowKey: The primary key of the alarm data record;

[0083] TableName: The data table being operated on;

[0084] Operation: The type of operation;

[0085] AfterImage: The new value after the operation

[0086] BNo / TNo: The block location to which the transaction belongs;

[0087] ts_commit: The actual write timestamp;

[0088] handler: The system / module / user that initiates or executes this transaction;

[0089] attack_type: The type of alarm event;

[0090] severity: The threat level;

[0091] src_ip: The source IP address of the attack;

[0092] event_time: The original timestamp when the alarm detection occurred;

[0093] tx_hash: The hash value calculated by the system before writing, which is used for data integrity verification;

[0094] These fields support common analysis operations, such as: querying the change trend of the number of high-risk alarms (based on severity + event_time); counting the number of different attack alarms (based on attack_type); aggregating and analyzing by the source of the attack (based on src_ip); among them, tx_hash is calculated by Peer nodes after passing the Validate stage in the EOV model and before writing, ensuring that the hash value is based on the finally written data to prevent consistency problems caused by early binding:

[0095] tx_hash = SHA256(rowKey + TableName + Operation + AfterImage)

[0096] Such rwT retains the core fields for verification and analysis, which not only meets the traceability of on-chain transactions but also controls the storage and computing overheads, and is applicable to the basic modeling and auditing requirements of large-scale alarm on-chain systems.

[0097] Step 4: Use the Execute-Order-Validate model to perform consensus processing on the rwT metadata;

[0098] The method for performing consensus processing is as follows:

[0099] After completing the encapsulation of alarm data and the generation of rwT triples, the system enters the core process of blockchain transaction processing - the EOV (Execute→Order→Validate) model stage. The goal of this stage is to ensure the verifiability, consistency, and immutability of data writing through processes such as simulated execution, consensus ordering, and conflict verification;

[0100] First, in the Execute stage, the client submits the constructed SQL transaction to the chaincode interface. After receiving the proposal, the Peer node does not immediately modify the state but converts the SQL statement into a corresponding read-only SQL query for simulated execution and generation of read-write sets. For example:

[0101] SELECT*FROM alerts WHERE alert_id='AL1234';

[0102] The Peer node reads the data snapshot related to this record in the local database, generates the ReadSet (primary key and version information of the read record) and WriteSet (new value to be written, field change, etc.) of the transaction, and encapsulates the rwT of the transaction together with the read-write set as a proposal response; the client collects endorsement signatures from multiple Peers and constructs the final transaction proposal; no write operations are performed in this stage, ensuring the determinism and reproducibility of the simulation process;

[0103] Then it enters the Order stage. After the client collects sufficient endorsement signatures, it submits the SQL proposal to the Orderer service (such as the Kafka consensus module). The Orderer node globally sorts multiple transactions in the submission order to form a block structure:

[0104]

[0105] The sorted block is broadcast to all Peer nodes, triggering the entry into the verification stage;

[0106] In the Validate phase, each Peer node sequentially performs version validation on the transactions in the block, checking whether the version information recorded in the ReadSet of each transaction is consistent with the current on-chain state to prevent concurrent write conflicts or replay attacks. Only transactions that pass the version validation will enter the actual write phase; for all transactions that pass the validation, before the system officially writes to the database, it calculates the hash digest tx_hash of the transaction, and this hash is written to the tx_hash field in the rw_transaction table for subsequent on-chain data verification, cross-chain auditing, block digest calculation, and other purposes; then, the system performs the following write operations: write the alarm data to the alerts table; write the transaction triples to the rw_transaction table; record the version information in the history_table; write the block digest, hash, and time to the block_table; these writes are identified by the block number BNo and the transaction number TNo, constituting the unique location of the on-chain transaction.

[0107] Step 5: Write the data that has passed consensus validation to the SQL-enhanced blockchain;

[0108] After the transactions are sorted and version-validated, the system enters the official write phase of the on-chain data; to support multiple requirements such as structured query, on-chain auditing, multi-version traceability, and block consistency verification, the system adopts the SQL-enhanced hybrid storage architecture proposed by aChain, writing different types of data to logically independent tables respectively to meet the dual goals of hierarchical storage and efficient analysis;

[0109] First, the current status of the alert data is written to the main data table alerts, which stores the latest effective alert information. The structured fields include alert_id, src_ip, severity, attack_type, event_time, etc.; all operations such as querying, visualizing, and trend analyzing alerts are based on this table as the data foundation. The system also supports automatically creating indexes according to alert frequency or transaction suggestion fields, such as fields like event_time and severity, to improve retrieval efficiency. Secondly, the system writes the rwT triple structure records generated by each SQL write transaction to the rw_transaction table. This table not only contains the core fields of the transaction triples, such as rowKey, TableName, Operation, AfterImage, but also includes the context fields required for business analysis, such as event_time, src_ip, attack_type, severity, as well as the hash digest field tx_hash and the write time ts_commit; these structures constitute a verifiable audit trail for on-chain data changes. While ensuring the state can be restored, the system also saves the historical versions of each write in the history_table; this table records the evolution track of the same alert record being modified in multiple transactions, including version identifiers, original state snapshots, and write times; through this table, the system can achieve time playback based on transaction versions, data difference comparison, and state tracking. In addition, to achieve data integrity verification at the block level, each block aggregates the hash values of all transactions it contains to build a Merkle tree, and writes the root hash merkle_root, block hash block_hash, and block meta-information to the block_table; this structure can not only be used to quickly verify whether any transaction has been tampered with, but also supports fast range queries and on-chain integrity audits based on block numbers and timestamps.

[0110] Through the cooperation of these four layers of data tables, the system realizes a complete hybrid on-chain storage system with queryable data status, traceable transaction behaviors, restorable historical processes, and verifiable block data, providing a solid data foundation for subsequent alert analysis, trend prediction, attack aggregation, and security modeling.

[0111] The present invention adopts blockchain distributed storage and consensus mechanisms to ensure the credibility and verifiability of alert data shared between different organizations, improve the cross-institutional security intelligence analysis ability, and support data traceability and privacy protection. The present invention can be widely applied to large-scale distributed security monitoring scenarios such as enterprise SOC (Security Operations Center), government security supervision, and financial risk control systems, and can provide high-throughput alert data storage, real-time query, distributed sharing, and intelligent attack analysis to meet the requirements of efficient, accurate, and secure data management in the network security environment.

[0112] Step 6: Complete the query and analysis of alert events from different sources in the SQL-enhanced blockchain.

[0113] After the alert data is written to the blockchain and structured and stored in core data tables such as alerts and rw_transaction, the system enters the analysis and response phase. To meet the requirements of efficient query and multi-dimensional statistics of on-chain data, the system provides comprehensive basic capabilities for security analysis based on the SQL-enhanced blockchain structure, combined with structured field indexing, transaction metadata, and time series support;

[0114] First, when the system constructs the transaction triple structure (rwT), it allows users or automatic engines to specify recommended query optimization fields in the transaction, such as severity, event_time, or src_ip; these fields will be recorded in the attr attribute of the rw_transaction table; the system's background index optimization module will periodically analyze the usage frequency and query pressure of these fields in the transaction and automatically create or update corresponding database indexes for the main table alerts, for example:

[0115] CREATE INDEX idx_alerts_severity_event_time ON alerts(severity,event_time);

[0116] In this way, without interfering with the business logic, the query path can be dynamically optimized, significantly improving the query performance; based on the structured storage and indexing mechanism, the system supports a series of query operations for security events, including common aggregation, grouping, filtering, and time trend analysis; for example, users can count the distribution ratio of current various attack types, analyze the evolution trend of alerts at different levels in the past week, identify frequently occurring attack source IPs, or trace back the change history of specified primary key records; all these queries can be expressed in standard SQL and can be directly run in the on-chain database, for example:

[0117] Analysis of high-risk alert trends (aggregated by date):

[0118] SELECT DATE(event_time),COUNT(*)FROM alerts

[0119] WHERE severity='HIGH'

[0120] GROUP BY DATE(event_time);

[0121] Statistics of the distribution of attack types:

[0122] SELECT attack_type, COUNT(*) FROM alerts

[0123] GROUP BY attack_type;

[0124] Top Active Source IPs (Last Three Days):

[0125] SELECT src_ip, COUNT(*) FROM alerts

[0126] WHERE event_time > NOW() - INTERVAL 3 DAY

[0127] GROUP BY src_ip ORDER BY COUNT(*) DESC;

[0128] By correlating the timestamp field event_time with the on-chain write time ts_commit, users can further analyze the detection latency, response time, and on-chain write efficiency of alerts;

[0129] SELECT alert_id, TIMESTAMPDIFF(SECOND, event_time, ts_commit) AS delay

[0130] FROM alerts JOIN rw_transaction USING(rowKey)

[0131] WHERE severity = 'HIGH';

[0132] To support more complex analysis requirements, the system also reserves multiple optimization spaces: for example, the alerts table can be automatically partitioned by day or week based on the time field to improve the query efficiency of historical data; the execution plan of high-frequency SQL queries can be cached to reduce the overhead of repeated parsing; frequent pattern mining can also be combined with the structured fields in rwT records to assist in identifying potential attack behavior models and attack chain patterns;

[0133] While ensuring the consistency and verifiability of on-chain transactions, the present invention integrates the structural advantages of SQL with the semantic requirements of the security analysis scenario, constructs a full-process on-chain analysis capability that can be queried, analyzed, and audited. Through this mechanism, the security team can more efficiently track the evolution path of security events, quickly respond to alerts, and timely capture abnormal behaviors and conduct threat identification and prediction.

[0134] Please refer to Figure 2, Correspondingly to the above method, according to an embodiment of the present invention, there is provided a blockchain-based network security alert data storage device, which is used to support the trusted recording, structured storage, index optimization and on-chain analysis of security alert data. The device includes the following functional modules:

[0135] Alert data collection and preprocessing module 101: This module is used to collect raw alert information from multiple security log sources, and the security log sources include but are not limited to: intrusion detection system (IDS), security information and event management platform (SIEM), Web access log, DNS resolution record, mail server log, network traffic log, etc.; This module supports streaming access through log collection tools such as Kafka, Fluentd, Logstash, or static log files can be collected by pulling them regularly through an interface. After the collection is completed, the log content is subjected to structure parsing, format cleaning, and field standardization processing to form a standardized alert record with a unified structure and clear semantics, which is used as the input for subsequent on-chain transaction encapsulation;

[0136] Alert transaction construction and encapsulation module 102: This module is used to convert the structured alert record into an SQL write transaction and synchronously construct the corresponding rwT triple structure; The SQL write transaction can include INSERT, UPDATE types, and the rwT includes fields such as rowKey, operation type Operation, changed content AfterImage, and custom extension field attr; Among them, the attr field allows developers to attach business label information (such as attack type, processing module, detection device, etc.) to each transaction; In addition, this module also converts the SQL write transaction into a read-only query statement based on the chaincode simulation logic, generates the corresponding ReadSet and WriteSet, and is used for consistency verification in the subsequent consensus process;

[0137] Blockchain transaction consensus processing module 103: This module completes the on-chain consensus processing of alert data transactions based on the EOV model, including the following steps: Peer nodes perform chaincode simulation execution on alert transactions in the Execute stage to generate read-write sets and transaction triples; After the client collects the endorsement signatures of multiple Peers, it submits the transaction to the Orderer (sorting service) node; The Orderer node sorts all received transactions in the global order, generates a new block and broadcasts it to all Peer nodes; Each Peer node performs version consistency verification according to the ReadSet information in the Validate stage. If the verification passes, it performs the formal write operation and generates a hash digest tx_hash for each transaction to ensure the non-repudiation of the transaction content;

[0138] On-chain Structured Storage Module 104: This module is used to write alarm data and its transaction behaviors records into a multi-layer structured storage database, including: writing alarm master data into the alerts table; generating rwT triples for each write operation and writing them into the rw_transaction table; writing historical status and version snapshots of alarm records into the history_table; writing hash information of each block and the Merkle tree root into the block_table; the four-layer structure supports structured query of alarm status, on-chain audit of transaction behaviors, version playback of status evolution, and block-level data integrity verification;

[0139] On-chain Analysis and Query Optimization Module 105: This module is used to support multi-dimensional statistics, trend analysis, and attack chain identification of alarm data, and at the same time implement SQL query path optimization based on behavior hints; this module periodically analyzes the attributes contained in the attr field of the rw_transaction table and automatically generates or updates the index structure for the alerts main table; this module also provides a series of SQL-based aggregation query capabilities, including but not limited to: high-risk alarm trend statistics, attack type distribution analysis, attack source IP activity ranking, alarm write delay evaluation, and multi-version historical backtracking query, etc.

[0140] Furthermore, as Figure 3 shown, the blockchain transaction consensus processing module 103 mainly includes the following parts:

[0141] Among them, the chain code simulation execution sub-module is used to receive SQL write transaction proposals from the client in the Peer node, and execute equivalent read-only SELECT query operations based on the current state database to generate the read set (ReadSet) and write set (WriteSet) of the transaction; the simulation execution does not change the state, but only constructs the transaction impact scope; the endorsement processing sub-module returns the simulation execution results (ReadSet, WriteSet) and the transaction triple (rwT) to the client together, and attaches the digital signature of the Peer node as an endorsement; the client forms a valid transaction proposal after collecting endorsements from multiple Peer nodes; the sorting service sub-module (Ordering Service) receives the complete endorsement proposal from the client, is responsible for sorting all transactions to be chained according to time or policy, encapsulates them into a new block structure (including block number BNo, transaction number TNo, transaction hash list tx_hash_list, timestamp, etc.), and broadcasts the block to all participating nodes; after each Peer node receives the block, the version consistency verification sub-module verifies whether the ReadSet of each transaction matches the current on-chain state item by item to ensure that the data has not been concurrently modified by other transactions. Only the transactions that pass the verification are marked as valid transactions and enter the writing stage; before writing, the hash generation and structure encapsulation sub-module calculates the transaction hash for each transaction for subsequent block verification and auditing. All transaction hashes form the Merkle root hash merkle_root, which is written into the block header to support fast verification; for the transactions that pass the verification, the data writing sub-module performs the following on-chain structured writing: write the current alarm state into the alerts table; write the rwT triple, transaction hash, and timestamp into the rw_transaction table; if it is an update operation, write the old value and version information into the history_table; write information such as block number, hash, and Merkle root into the block_table; all writes are subject to consensus constraints and have the on-chain characteristics of being auditable, immutable, and traceable; this module realizes the whole process from chain code execution, consensus sorting to state writing, providing strong consistency guarantee and multi-node verifiable chain data processing ability for the system.

[0142] Further, as Figure 4 shown, the on-chain structured storage module 104 includes:

[0143] Alert Status Master Table (alerts table): Used to store currently effective security alert records; each record corresponds to a primary key alert_id, and the fields include src_ip, dst_ip, severity, attack_type, event_time, etc.; all SQL queries for visual display, quick retrieval, aggregation analysis, etc. are based on this table; Module 105 will automatically build composite indexes based on the recommended fields in rw_transaction, such as event_time, severity, etc., to improve query efficiency; the data in the table only reflects the latest status and does not retain history;

[0144] Transaction Triplet Table (rw_transaction table): Used to record the rwT triplet structure and extended attributes of all SQL write transactions; this table is a structured implementation of the blockchain ledger function, supporting auditing, traceability, and query optimization;

[0145] Historical Version Record Table (history_table): Used to record the historical status snapshots of alert records in different transactions to achieve multi-version traceability; when an alert record is modified by an UPDATE operation, this table will save the original value, version number before the change, change time, etc.; rollback queries, data comparison, and restoration of the alert evolution track can be achieved through this table; by joining with the rw_transaction table, a complete life cycle chain of alerts can be constructed;

[0146] Block Header Index Table (block_table): Records the hash structure and index meta-information at the block level, simulating the block header function of the blockchain; used for scenarios such as verifying block integrity, transaction verifiability, and cross-chain references.

[0147] The present invention also provides a blockchain-based security alert data storage system, including:

[0148] An alert event collection module, used to collect alert events from network security management systems of different sources;

[0149] A structuring module, used to parse alert events from different sources and map them into structured alert data;

[0150] An SQL transaction construction module, used to encapsulate structured alert data into SQL write transactions and construct rwT metadata with transaction triplets in combination with the add, delete, modify, and query operations of alert data; the rwT metadata includes the primary key rowKey of the alert data record, operation type Operation, changed content AfterImage, and custom extended field attr; among them, the attr field allows developers to attach business label information to each transaction;

[0151] A consensus processing module for performing consensus processing on rwT metadata using the Execute-Order-Validate model;

[0152] A transaction writing module for writing the data after consensus verification into an SQL-enhanced blockchain;

[0153] A query and analysis module for completing query and analysis of alarm events from different sources in the SQL-enhanced blockchain.

[0154] The present invention also provides an electronic device, including a bus, a transceiver, a memory, a processor, and a computer program stored on the memory and executable on the processor. The transceiver, the memory, and the processor are connected through the bus. It is characterized in that when the computer program is executed by the processor, the steps in the above-mentioned method for securely storing trusted alarm data based on a blockchain are implemented. Compared with the prior art, the beneficial effects of the electronic device provided by the present invention are the same as those of the above-mentioned method for securely storing trusted alarm data based on a blockchain, and will not be elaborated here.

[0155] The present invention also provides a computer-readable storage medium, on which a computer program is stored. It is characterized in that when the computer program is executed by a processor, the steps in the above-mentioned method for securely storing trusted alarm data based on a blockchain are implemented. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present invention are the same as those of the above-mentioned method for securely storing trusted alarm data based on a blockchain, and will not be elaborated here.

[0156] In this specification, the various embodiments are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The same or similar parts among the various embodiments can be referred to each other. For the methods disclosed in the embodiments, since they correspond to the devices disclosed in the embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description of the device part.

[0157] In this article, specific examples are used to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. At the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation manner and application scope. In summary, the content of this specification should not be construed as a limitation on the present invention.

Claims

1. A method for securely storing trustworthy security alert data based on blockchain, characterized in that, Including: Step 1: Collect alarm events from network security management systems of different sources; Step 2: Parse alarm events from different sources and map them into structured alarm data; Step 3: Package the structured alarm data as SQL into a transaction, and construct rwT metadata with transaction triples in combination with the add, delete, update, and query operations of the alarm data; the rwT metadata includes the primary key rowKey of the alarm data record, the operation type Operation, the changed content AfterImage, and a custom extension field attr; among them, the attr field allows developers to attach business label information to each transaction; Step 4: Perform consensus processing on the rwT metadata using the Execute-Order-Validate model; Step 5: Write the data after consensus verification into an SQL-enhanced blockchain; Step 6: Complete the query analysis of alarm events from different sources in the SQL-enhanced blockchain.

2. The secure alarm data trustworthy storage method based on blockchain according to claim 1, wherein, The said Step 2: Parse alarm events from different sources and map them into structured alarm data, including: Parse alarm events from different sources to form alarm records; Extract key fields from the alarm records; Uniformly map the extracted key fields into a predefined standard field structure; Perform standardization and legality cleaning on the predefined standard field structure to form structured alarm data.

3. A secure alarm data trusted storage method based on blockchain according to claim 2, characterized in that, The said Step 3: Package the structured alarm data as SQL into a transaction, and construct rwT metadata with transaction triples in combination with the add, delete, update, and query operations of the alarm data; Package the structured alarm data as SQL into a transaction to form an SQL transaction; Convert the SQL transaction into a read-only SELECT query, which is simulated and executed by the Peer node to generate the expected data content WriteSet to be written or modified by this transaction, the read data records and their versions ReadSet; Construct rwT metadata with transaction triples in combination with the expected data content WriteSet to be written or modified by the transaction, the read data records and version information ReadSet, and the add, delete, update, and query operations of the alarm data.

4. A method for securely storing trusted security alert data based on blockchain according to claim 3, characterized in that, The said Step 4: Perform consensus processing on the rwT metadata using the Execute-Order-Validate model, including: In the Execute phase, the client submits the constructed SQL transaction to the chain code interface; After receiving the proposal, the Peer node converts the SQL statement into a corresponding read-only SQL query, generates the ReadSet and WriteSet of the transaction, and packages the rwT metadata of the transaction together with the read-write set as a proposal response and generates a corresponding endorsement signature; In the Order phase, after the client collects a preset number of endorsement signatures, it constructs a final transaction proposal and submits the final transaction proposal to the Orderer service node; The Orderer service node globally sorts the final transaction proposals in the submission order to form a block structure: The sorted blocks are broadcast to all Peer nodes and enter the Validate phase; In the Validate phase, each Peer node sequentially performs version verification on the transactions in the block, checking whether the version information recorded in the ReadSet of each transaction is consistent with the current on-chain state; Extract all the transactions that pass the version verification, calculate the hash digest tx_hash of the transaction, and write it into the tx_hash field in the rw_transaction table as the data after consensus verification.

5. A secure alarm data trusted storage method based on blockchain according to claim 4, characterized in that, Step 5: Write the data after consensus verification into the SQL-enhanced blockchain, including: Write the alarm data into the alerts table for querying, visual display, and trend analysis of the alarms; Write the transaction triple rwT into the rw_transaction table and record the version information in the history_table to enable time playback based on transaction versions, data difference comparison, and status tracking; Aggregate the hash values of all transactions included in each block to construct a Merkle tree, and write the root hash merkle_root, block hash block_hash, and block metadata into the block_table for verifying whether any transaction has been tampered with.

6. A blockchain-based secure alarm data storage system, characterized in that, Including: An alarm event collection module for collecting alarm events from network security management systems of different sources; A structuring module for parsing alarm events from different sources and mapping them into structured alarm data; An SQL transaction construction module for encapsulating the structured alarm data into an SQL write transaction and constructing rwT metadata with transaction triples in combination with the add, delete, modify, and query operations of the alarm data; the rwT metadata includes the primary key rowKey of the alarm data record, the operation type Operation, the changed content AfterImage, and a custom extension field attr; where the attr field allows developers to attach business label information to each transaction; A consensus processing module for performing consensus processing on the rwT metadata using the Execute-Order-Validate model; A transaction writing module for writing the data after consensus verification into the SQL-enhanced blockchain; A query analysis module for completing query analysis of alarm events from different sources in the SQL-enhanced blockchain.

7. An electronic device, comprising a bus, a transceiver, a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the transceiver, the memory, and the processor are connected through the bus, and is characterized in that, When the computer program is executed by the processor, it implements the steps in a method for trusted storage of security alarm data based on blockchain as described in any one of claims 1-5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps in a method for trusted storage of security alarm data based on blockchain as described in any one of claims 1-5.

Images