A verification method for centralized control of trusted data collection

Abstract

The present invention discloses a verification method for centralized control of trusted data collection, characterized by verifying the non-repudiation of the collected data after encryption by Algorithm 1. Based on a process control model, the entire hacker attack process is divided into seven stages: reconnaissance, delivery, installation, privilege escalation, lateral movement, target operation, and withdrawal. Log data corresponding to each of the seven stages is collected, and two different storage devices, α and β, are used to store the collected data. β is an external storage device for collected data, which is physically disconnected and stored in a safe place. Both α and β are initialized to zero. The generated key stream K is stored in both devices α and β. When verification begins, the β device is connected. If verification is successful, the auditor will search for evidence of hacker intrusion in the log entries generated in the five stages of reconnaissance, delivery, installation, privilege escalation, and lateral movement. Through the present invention, it is possible to find real traces of hacker attacks.

Description

Technical Field

[0001] The present invention relates to the technical fields of network security, SOC (Security Operation Center), trusted data collection, operating systems, file systems and data encryption, and in particular to a verification method for centralized control of trusted data collection. Background Art

[0002] Trusted data collection, as part of the centralized management and control of a security operations service platform, must maintain the availability, integrity, and non-repudiation of collected log data. This means that logs can be verifiably linked to events that occurred on a specific system. In security logs, verification occurs during dispute resolution. Specifically, when an intrusion attack occurs and is recorded in a log file, disputes arise. Both the intruder and the victim may attempt to deny the authenticity of the evidence. Auditors must then verify that the logs have not been modified since their generation.

[0003] To this end, how to ensure that log data is not denied; simply encrypting the collected data is not enough, and a verification algorithm for encrypting the collected data needs to be developed to achieve authentic and reliable data collection under centralized control. Summary of the Invention

[0004] In order to solve the above technical problems, the present invention provides a verification method for centralized control of trusted data collection, which verifies the encrypted collected data based on the process control model to ensure the non-repudiation of the collected data.

[0005] A verification method for centralized control of trusted data collection is characterized by verifying the non-repudiation of the collected data after encryption by Algorithm 1. Based on the process control model, the entire process of hacker attacks is divided into seven stages: reconnaissance, delivery, installation, privilege escalation, lateral movement, operation target and withdrawal. Log data corresponding to the seven stages are collected respectively. Two different storage devices, α and β, are used to store the collected data respectively. β is an external storage device for collected data, which is physically disconnected and stored in a safe place. Both α and β are initialized to zero. The generated key stream K is stored in the two devices α and β. α The key stream is stored in α, K β The key stream is stored in β, K α header.id represents the ID of the key stream, K α header.off indicates the current offset of the key stream, file ASEAL log Used to store the authentication data and metadata of the log. The field R.Loff represents the offset of the record R in the log file L. When verification begins, the β device is connected. The method includes the following steps:

[0006] (1) The size and ID of the key stream match, and the burned area is in K α End at header.off, otherwise, verification fails;

[0007] (2) Key stream burn area, in K α header.off before and after K α header.off, are different from those in K α and K β Otherwise, the verification fails;

[0008] (3) Given two consecutive ASEALs log Record that their corresponding blocks are continuous, otherwise, verification fails;

[0009] (4) The records R of the log file L are sorted by R.Loff to file ASEAL log , then by the file ASEAAL log The data area defined by record R is continuous; otherwise, there are gaps and verification fails;

[0010] (5) If all of the above are true and verification is successful, the auditor will look for evidence of hacker intrusion in the log entries generated during the five phases of reconnaissance, delivery, installation, privilege escalation, and lateral movement.

[0011] The technical effects of the present invention are:

[0012] In the present invention, a verification method for centralized control of trusted data collection is provided, which is characterized in that the non-repudiation of the collected data after being encrypted by algorithm 1 is verified. Based on the process control model, the entire process of hacker attack is divided into 7 stages: reconnaissance, delivery, installation, privilege escalation, lateral movement, operation target and withdrawal. Log data corresponding to the 7 stages are collected respectively. Two different storage devices α and β are used to store the collected data respectively. β is an external storage device for collected data, which is physically disconnected and stored in a safe place. Both α and β are initialized to zero. The generated key stream K is stored in the two devices α and β. When verification starts, the β device is connected. The method includes the steps of: (1) the size and ID of the key stream are matched, and its burned area is in K α header.off; (2) The key stream burn area, at K α header.off before and after K α header.off, are different from those in K α and K β Between; (3) Given two consecutive ASEAL logRecords, their corresponding blocks are continuous; (4) The records of log file L are sorted by R.Loff file ASEAL log , then the file ASEAL log The data area defined by the record is continuous; (5) If all of the above are true and the verification is successful, the auditor will search for evidence of hacker intrusion in the log entries generated in the five stages of reconnaissance, delivery, installation, privilege escalation, and lateral movement. Through the present invention, it is possible to find the real traces of the hacker's attack. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 It is a schematic diagram of a process control model for a verification method of centralized control of trusted data collection;

[0014] Figure 2 It is an encryption diagram of Algorithm 1 of a verification method for centralized control of trusted data collection;

[0015] Figure 3 It is a verification diagram of Algorithm 2 of a verification method for centralized control of trusted data collection;

[0016] Figure 4 Schematic diagram of the steps of Algorithm 2 of a verification method for centralized control of trusted data collection. DETAILED DESCRIPTION

[0017] The following is a further detailed description of the present invention based on the accompanying drawings and examples:

[0018] As a centrally managed and trusted data collection platform for security operations and maintenance services, the requirement is to maintain the availability, integrity, and non-repudiation of the collected log data. This means that logs can be verifiably linked to events that occurred on a specific system. In security logs, verification occurs during dispute resolution. Specifically, when an intrusion occurs and is recorded in a log file, disputes arise. Both the intruder and the victim may attempt to deny the authenticity of the evidence. Auditors must then be able to verify that the logs have not been modified since their generation.

[0019] Figure 1 This is a schematic diagram of a process control model for a centralized control and verification method of trusted data collection. The centralized control adopts a novel process control model for intrusion. Among the existing models, none is an ideal model suitable for human security operation and maintenance processes, automated association, and prediction and early warning. The process control model divides the entire process of hackers launching an attack into four logical domains: network stage, endpoint stage, domain stage, and evacuation stage. Furthermore, these four stages include reconnaissance, delivery, installation, privilege escalation, lateral movement, operational target, and evacuation, and are defined as follows:

[0020] Reconnaissance: Researching, identifying, and selecting targets, often manifested as crawling internet sites, such as conference proceedings and mailing lists, to obtain email addresses, social connections, or specific technical information.

[0021] Delivery: The transfer of weapons to the target environment. According to observations, the three most common delivery vectors for weaponized payloads by APT actors are email attachments, websites, and USB removable media. These weapons, which combine remote access Trojans with exploits and other tools, are typically delivered through automated tools, with phishing emails being a common method. Increasingly, client-side application data, such as Adobe Portable Document Format (PDF) or Microsoft Office documents, are becoming weaponized deliverables. For example, a phishing email includes a benign PDF and a Portable Executable (PE) backdoor installation file, encrypted using a common algorithm with an 8-bit key stored within the shellcode. Upon opening the PDF, the shellcode exploiting CVE-2009-0658 decrypts the installation binary, saves it to the machine's disk as C:\Documents and Settings\[username]\Local Settings\fssm32.exe, and then invokes it. The shellcode also extracts the benign PDF and displays it to the user.

[0022] Installation: Installing a remote access Trojan or backdoor on a system in a target environment allows hackers to maintain persistence in that environment. For example, the installer fssm32.exe will extract the backdoor component embedded in itself and save the exe and HLP files to C:\Program files\internetexplorer\IEUpd.exe and IEXPLORE.HLP.

[0023] Privilege escalation: Exploiting the startup or call of the operating system to automatically execute a remote access Trojan horse or backdoor program installed on the target network host to elevate the attacker's privileges. For example, shellcode can be used to elevate privileges (from normal privileges to root privileges in Linux).

[0024] Lateral Movement: Achieving their objectives typically requires exploring the target network to locate their target and subsequently gain access. This often requires accessing multiple systems and accounts. Hackers may use remote access Trojans or backdoors already installed on the target network to accomplish lateral movement, or they may use legitimate credentials for local network and operating system tools, internal phishing, SSH, web session cookies, and other techniques.

[0025] Operational Objective: Only now, after the first six stages, can the intruder take action to achieve their initial objective. Typically, this objective is data theft, including collecting, encrypting, and extracting information from the victim's environment; compromising data integrity or availability is also a potential goal. Alternatively, the intruder may simply wish to access the initial target to use as a jumping-off point for compromising another system and moving laterally within the network.

[0026] Evacuation: Once data is exfiltrated from a target network, hackers typically package it to avoid detection when deleting it. This can include compression and encryption. Techniques for extracting data from a target network typically involve transmitting the data through its command and control (C2) channels or alternate channels and transferring that data to an external network for storage.

[0027] Based on the process control model, when an enterprise network is attacked by hackers, it can be divided into the following three stages:

[0028] Phase 1: The network phase of the process control model, during which the enterprise network system operates normally without any intrusion. During this phase, attackers will scout and detect weaknesses or vulnerabilities in the system and attempt different remote or local attacks based on the attack vector. Log files can capture the attack type and attacker information at this phase.

[0029] Phase 2: This is the lateral movement phase of the process control model, which extends from the endpoint and domain phases. It begins when a system is compromised and the attacker is inside the enterprise network but does not have full control. During this phase, the attacker attempts to escalate privileges; logs may capture some traces of this phase, but the attacker may find it easier to conceal malicious actions.

[0030] Phase 3: The operational target phase or evacuation phase of the domain phase of the process control model. The attacker elevates permissions and fully controls the machine. The attacker can delete and manipulate logs to make the traces of the attack disappear.

[0031] From this, we can see that an attacker cannot bypass the centralized control in the first and second stages, and needs administrative privileges to do so, but can perform any operation in the third stage, such as deleting logs. Figure 2The illustrated algorithm 1 can ensure that an attacker cannot forge authentication data or recover the key used to generate the authentication data, because the used key has been burned and / or deleted.

[0032] Figure 2 This is an encryption diagram of Algorithm 1 of a verification method for centralized control of trusted data collection. It uses two different storage devices, α and β. β is the external storage device for the log, and involves the following parameters:

[0033] 1. Generate a random Keystream K;

[0034] 2. K is stored in two devices (binary format files containing a header). α The keystream is stored in α, K β The keystream is stored in β.

[0035] 3. K α and K β The header has been initialized. They have two fields, one field is: K α header.id, which is the id number of the key stream, where K α and K β will be shared to pair them; the other field is: K α header.off, which is the current offset into the keystream, is initialized to zero on both α and β.

[0036] 4. The β is physically disconnected from the system and stored in a safe place.

[0037] 5. The system creates a file ASEAL log To store the authentication data and metadata of the logs.

[0038] like Figure 2 The encryption method shown, when writing to a log, involves HMAC(key, msg). HMAC(key, msg) is a secure keyed-hash message authentication code algorithm. The input to the HMAC(key, msg) function is a key and a message. The output is a secure digest of the message that depends on the key.

[0039] As shown in Figure 2, the encryption algorithm only allows additional write operations (i.e., write operations at the end of the log). i Data D i Must be appended to the offset Loff iWhen the log file L is located, perform the following steps:

[0040] A centralized and controlled trusted data collection encryption method, characterized in that the method comprises the following steps:

[0041] (1) Set the size to Dsz i Data D i Add to offset Loff i In the log file L;

[0042] (2)K α The current offset of is read from its header;

[0043] (3)K α A block C i The block size is a constant Csz, which determines the key length consumed each time the log file L is written, and is independent of the size of the log file written;

[0044] (4)K α The corresponding area is added with data D i ;

[0045] (5)K α The latest offset is written to its header;

[0046] (6) HMAC of the concatenation of the id of the log file L, which uniquely identifies the log file and calculates the offset Loff of the log file L i , data length Dsz i , K α C in i Block offset Coff i and data D i , block C i Encrypted, and different blocks C i The encrypted keys are different, otherwise they will be decrypted by the attacker, so that the attacker can modify all logs related to the attacker;

[0047] (7) The block C i deleted from memory;

[0048] (8) Create a file with fields L and Loff i 、Dsz i 、Coff i and HMAC record R;

[0049] (9) Record R is attached to ASEAL log middle.

[0050] The above steps (2)–(9) must be performed atomically to keep K α header.off integrity and ASEAL log This is done from the perspective of algorithmic concurrency. If this invariant is not preserved, it will still be detected in the audit.

[0051] The system requires additional space to store the four integer values ​​and the HMAC digest for each write operation (regardless of the number of bytes written to the log file per append operation).

[0052] Figure 3 This is a verification diagram of Algorithm 2 of a verification method for centralized control of trusted data collection, which is used to verify whether the log file encrypted based on Algorithm 1 has been tampered with by hackers. Figure 4 This is a schematic diagram of the steps of Algorithm 2 of a verification method for centralized control of trusted data collection. First, connect to the β device and execute Algorithm 2.

[0053] First, check the keystream: their size and id number must match, and the burned area must be in K α header.off ends. Then, verify ASEAL in turn log Please note:

[0054] (1) The key stream is burned in sequence. α header.off must be preceded by K α and K β Different, and the same afterwards (unburned).

[0055] (2) Given two consecutive records, their corresponding blocks must be consecutive. K It is used for inspection.

[0056] (3) The records belonging to log L are in ASEAL log The log files are sorted in O[] (sorted by the R.Loff field). Therefore, the data area defined by its records must be continuous: if there are gaps, verification will fail. This is checked using an array, O[], with the position of each log file.

[0057] From K β Read the corresponding block of keystream (at offset R.Coff), read the data described by the record from L (from position R.Loff, length R.Dsz), and regenerate the HMAC using the block as the key. The new HMAC is compared with the HMAC stored in R. If they are not equal, verification of L fails.

[0058] If the HMAC is secure, the attacker cannot infer the log Therefore, she will not be able to forge the key of any record in ASEAL log Any HMAC of .

[0059] If hackers from ASEAL log If any record of log L is deleted from L, verification fails (line 14). It also fails if any log file is truncated or shortened (line 14). If a hacker modifies any field of any record belonging to L or its data, verification will fail because the HMAC will not match (line 21).

[0060] Modular log verification (i.e., verifying only a portion of L) is performed in a similar manner. In this case, only the records in the corresponding region of a specific log file are checked. Note that in this case, only the checked region of this log file can be declared untampered with. Other regions of this log file (or any other log file) may have been tampered with, and the file may be truncated.

[0061] The above description is only a preferred embodiment of the present invention and is not intended to limit the scope of implementation of the present invention; all equivalent changes and modifications made according to the present invention are deemed to be covered by the patent scope of the present invention.

Claims

1. A verification method for centralized control of trusted data collection, characterized in that: Verify the non-repudiation of the collected data after encryption by Algorithm 1. Based on the process control model, the entire process of hacker attacks is divided into 7 stages: reconnaissance, delivery, installation, privilege escalation, lateral movement, operation target and withdrawal. Collect the log data corresponding to the 7 stages respectively. Use two different storage devices α and β to store the collected data respectively. β is the external storage device for collected data. It is physically disconnected and initialized to zero on both α and β. The generated key stream K is stored in the two devices α and β, which are K α With K β Among them, K α The key stream is stored in α, K β The key stream is stored in β, K α header.id represents the ID of the key stream, K α header.off indicates the current offset of the key stream, file ASEAL log Used to store the authentication data and metadata of the log. The field R.Loff represents the offset of the record R in the log file L. When verification begins, the β device is connected. The method includes the following steps: (1) The size and ID of the key stream match, and the burned area is in K α End at header.off, otherwise, verification fails; (2) Key stream burn area, ensure that α K before header.off α Keystream and K β K before header.off β The key stream is different, while ensuring that α K after header.off α Keystream and K β K after header.off β The key streams are the same, otherwise, verification fails; (3) Given two consecutive ASEALs log Record that their corresponding blocks are continuous, otherwise, verification fails; (4) The records R of the log file L are sorted by the size of the R.Loff field to sort the file ASEAL log , then the file ASEAL log The data area defined by the record R is continuous; otherwise, there are gaps and the verification fails; (5) If all of the above are true and verification is successful, the auditor will look for evidence of hacker intrusion in the log entries generated during the five phases of reconnaissance, delivery, installation, privilege escalation, and lateral movement.

Images