Detection method for communication abnormity of cipher machine, electronic equipment, storage medium and computer program product

Abstract

The invention provides a cipher machine communication abnormity detection method, electronic equipment, a storage medium and a computer program product, and the method comprises the steps: screening out a to-be-detected cipher machine based on a negotiation log among a plurality of cipher machines, and generating a first event log; judging whether the cipher machine to be detected is a target cipher machine or not according to the first event log and a communication log of flow data passing through each cipher machine, and if yes, generating a second event log; and according to the second event log and the communication log, judging whether the output port of the target cipher machine has unencrypted data, and if so, determining that the communication of the target cipher machine is abnormal. Through the measures, the cipher machine with abnormal communication can be effectively detected in the scene of multiple cipher machines.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a method for detecting abnormal communication of a cryptographic machine, an electronic device, a computer-readable storage medium, and a computer program product. Background Art

[0002] In the field of information security technology, cryptographic machines are widely used for data encryption, decryption and other operations to protect the security of sensitive information. However, there are some malicious behaviors, such as illegal data interaction by skipping the normal communication path of the cryptographic machine, which may bypass the security protection mechanism of the cryptographic machine and cause sensitive data leakage or malicious attacks.

[0003] In the relevant scheme, the traffic probe device will report the traffic data logs collected by the switch mirror ports on both sides of the cipher machine. When unencrypted traffic data appears in the reported traffic data logs, it can be determined that the communication of the cipher machine is abnormal. Here, both sides of the cipher machine refer to the input port and output port of the cipher machine.

[0004] However, when multiple cryptographic machines are deployed in a network environment, due to the lack of corresponding information in the traffic data log, it is impossible to determine which cryptographic machine the unencrypted data has passed through, and it is also impossible to locate the cryptographic machine with communication anomalies, which will lead to continuous unencrypted communication and cause sensitive data leakage. Summary of the invention

[0005] The purpose of the embodiments of the present application is to provide a method for detecting communication anomalies of a cryptographic machine, an electronic device, a computer-readable storage medium, and a computer program product, which are used to effectively detect cryptographic machines with communication anomalies in a multi-cryptographic machine scenario.

[0006] On the one hand, the present application provides a method for detecting abnormal communication of a cryptographic machine, comprising:

[0007] Based on the negotiation logs between multiple cryptographic machines, the cryptographic machine to be detected is screened out, and a first event log is generated; wherein the negotiation log records the initiator and receiver of the negotiation data, and the status of the negotiation data; the first event log indicates that the status of the negotiation data initiated by the cryptographic machine to be detected is abnormal;

[0008] According to the first event log and the communication log of the flow data passing through each cipher machine, it is determined whether the cipher machine to be detected is the target cipher machine, and if so, a second event log is generated; wherein the communication log records the source cipher machine identification, the destination cipher machine identification, the data collection location, and the encryption status of the flow data; the second event log indicates that there is no encrypted flow data at the output port of the target cipher machine;

[0009] Based on the second event log and the communication log, determine whether there is unencrypted data at the output port of the target cryptographic machine. If so, determine that the communication of the target cryptographic machine is abnormal.

[0010] Through the above content, with the help of logs containing rich information, in the scenario of multiple cipher machines, we can first screen out the cipher machines to be detected that cannot communicate normally with other cipher machines, and then determine whether the cipher machine to be detected is a target cipher machine through which no encrypted traffic data passes, and if the target cipher machine has unencrypted data passing through, determine that the target cipher machine has communication anomalies; in this case, we can effectively locate the cipher machine with communication anomalies in the scenario of multiple cipher machines, and avoid bypassing the cipher machine due to communication anomalies, resulting in sensitive data leakage or malicious attacks. This process can be automated, reducing the cost of manual investigation and improving the efficiency of detecting cipher machines with communication anomalies.

[0011] In one embodiment, before screening out the cryptographic machines to be detected based on the negotiation logs between the multiple cryptographic machines and generating the first event log, the method further includes:

[0012] When the negotiation data is collected, a negotiation log is generated according to the state, source cipher machine identifier and target cipher machine identifier in the negotiation data.

[0013] Through this measure, when the cipher machines negotiate with each other, a negotiation log can be generated through the negotiation data, so that the cipher machine to be detected that cannot communicate with other cipher machines can be identified with the help of the negotiation log.

[0014] In one embodiment, the step of screening out the cryptographic machines to be detected based on the negotiation logs between the multiple cryptographic machines includes:

[0015] If there is a negotiation log indicating that the status of the negotiation data sent from the first cryptographic machine to the second cryptographic machine is successful, and there is a negotiation log indicating that the status of the negotiation data sent from the second cryptographic machine to the first cryptographic machine is abnormal, the second cryptographic machine is used as the cryptographic machine to be detected.

[0016] Through this measure, the cipher machines to be detected that cannot communicate with other cipher machines can be limitedly screened out based on the negotiation log.

[0017] In one embodiment, the step of generating the communication log includes:

[0018] When flow data is collected from a preset data collection location, the preset cipher machine configuration table is searched with the source IP of the flow data to determine the cipher machine identifier corresponding to the network segment to which the source IP belongs, as the source cipher machine identifier of the flow data; wherein the cipher machine configuration table records the mapping relationship between multiple network segments and cipher machine identifiers;

[0019] Search the cipher machine configuration table according to the destination IP of the traffic data, determine the cipher machine identifier corresponding to the network segment to which the destination IP belongs, and use it as the destination cipher machine identifier of the traffic data;

[0020] Check the encryption status of the traffic data, and generate a communication log corresponding to the traffic data based on the encryption status, the data collection location of the traffic data, the source cipher machine identifier and the destination cipher machine identifier.

[0021] Through this measure, a communication log containing richer content can be generated for the traffic data collected at each data collection location, so as to facilitate the subsequent detection task of abnormal communication of the cryptographic machine.

[0022] In one embodiment, judging whether the cryptographic machine to be detected is a target cryptographic machine based on the first event log and the communication log of the traffic data passing through each cryptographic machine includes:

[0023] Parsing the cryptographic machine identifier of the cryptographic machine to be detected from the first event log, and filtering out the communication logs whose source cryptographic machine identifier matches the cryptographic machine identifier of the target cryptographic machine;

[0024] Determine whether there is a communication log in the filtered communication logs whose data collection location is an output port and whose encryption state is encrypted;

[0025] If not present, it is determined that the cryptographic machine to be detected is the target cryptographic machine.

[0026] Through the above measures, a logical judgment can be performed on the communication log that matches the cipher machine identifier of the cipher machine to be detected in the first event log, thereby effectively determining whether the cipher machine to be detected is the target cipher machine.

[0027] In one embodiment, judging whether there is unencrypted data at the output port of the target cryptographic machine based on the second event log and the communication log, and if so, determining that the communication of the target cryptographic machine is abnormal, includes:

[0028] Parsing the cryptographic machine identifier of the target cryptographic machine from the second event log, and filtering out the communication logs whose source cryptographic machine identifier matches the cryptographic machine identifier of the cryptographic machine to be detected;

[0029] Determine whether there is a communication log in the filtered communication logs whose data collection location is the output port and whose encryption status is unencrypted;

[0030] If so, it is determined that the target cryptographic machine has communication abnormalities.

[0031] Through the above measures, a logical judgment can be performed on the communication log that matches the cipher machine identifier of the cipher machine to be detected in the second event log, thereby effectively determining whether the target cipher machine has communication abnormalities.

[0032] In one embodiment, the communication log records the organization information corresponding to the source cryptographic machine identification;

[0033] After determining that the target cryptographic machine has abnormal communication, the method further includes:

[0034] Generate an alarm message based on the cipher machine identification and organization information of the target cipher machine in the communication log; wherein the alarm message indicates that the target cipher machine has abnormal communication.

[0035] Through this measure, alarm information of cryptographic machines with abnormal communication can be generated based on rich log information, so that cryptographic machines with abnormal communication can be reported in time.

[0036] On the other hand, the present application provides a method and device for detecting abnormal communication of a cryptographic machine, comprising:

[0037] A first generating module is used to screen out the cryptographic machine to be detected based on the negotiation logs between the multiple cryptographic machines, and generate a first event log; wherein the negotiation log records the initiator and the receiver of the negotiation data, and the state of the negotiation data; the first event log indicates that the state of the negotiation data initiated by the cryptographic machine to be detected is abnormal;

[0038] A second generating module is used to determine whether the cipher machine to be detected is a target cipher machine based on the first event log and the communication log of the flow data passing through each cipher machine, and if so, generate a second event log; wherein the communication log records the source cipher machine identifier, the destination cipher machine identifier, the data collection location, and the encryption status of the flow data; and the second event log indicates that there is no encrypted flow data at the output port of the target cipher machine;

[0039] A determination module is used to determine whether there is unencrypted data at the output port of the target cryptographic machine based on the second event log and the communication log, and if so, determine that the communication of the target cryptographic machine is abnormal.

[0040] On the other hand, the present application provides an electronic device, the electronic device comprising:

[0041] processor;

[0042] a memory for storing processor-executable instructions;

[0043] Wherein, the processor is configured to execute the above-mentioned method for detecting abnormal communication of the cryptographic machine.

[0044] Furthermore, the present application provides a computer-readable storage medium, which stores a computer program, and the computer program can be executed by a processor to complete the above-mentioned method for detecting communication anomalies of a cryptographic machine.

[0045] In addition, the present application provides a computer program product, including a computer program / instruction, which implements the above-mentioned method for detecting communication anomalies of a cryptographic machine when the computer program / instruction is executed by a processor. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the technical solution of the embodiments of the present application, the drawings required for use in the embodiments of the present application are briefly introduced below.

[0047] Figure 1 A schematic diagram of an application scenario of a method for detecting abnormal communication of a cryptographic machine provided in an embodiment of the present application;

[0048] Figure 2 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application;

[0049] Figure 3 A flowchart of a method for detecting abnormal communication of a cryptographic machine provided in an embodiment of the present application;

[0050] Figure 4 A flow chart of a method for generating a communication log provided in an embodiment of the present application;

[0051] Figure 5 An embodiment of the present application provides Figure 3 Detailed flow chart of step 320;

[0052] Figure 6 An embodiment of the present application provides Figure 3 Detailed flow chart of step 330;

[0053] Figure 7 A block diagram of a device for detecting abnormal communication of a cryptographic machine provided in one embodiment of the present application. DETAILED DESCRIPTION

[0054] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0055] Similar reference numerals and letters represent similar items in the following drawings, so once an item is defined in one drawing, it does not need to be further defined and explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and cannot be understood as indicating or implying relative importance.

[0056] Figure 1A schematic diagram of an application scenario of the method for detecting abnormal communication of a cryptographic machine provided in an embodiment of the present application. Figure 1 As shown, the application scenario includes a client 20 and a server 30; the client 20 can be a key network device such as a core switch or a firewall in the network where the cryptographic machine is located. The client 20 installs traffic monitoring software or enables the hardware monitoring function, and can upload the collected traffic data to the server 30; the server 30 can be a server, a server cluster or a cloud computing center equipped with an analysis platform, which can generate log information for the traffic data and detect whether there is a cryptographic machine with abnormal communication in the network environment based on the log information.

[0057] like Figure 2 As shown, this embodiment provides an electronic device 1, including: at least one processor 11 and a memory 12, Figure 2 A processor 11 is taken as an example. The processor 11 and the memory 12 are connected via a bus 10. The memory 12 stores instructions that can be executed by the processor 11. The instructions are executed by the processor 11 so that the electronic device 1 can execute all or part of the process of the method in the following embodiment. In one embodiment, the electronic device 1 can be the above-mentioned server 30, which is used to execute the detection method of abnormal communication of the cryptographic machine.

[0058] The memory 12 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable red-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, disk or optical disk.

[0059] The present application also provides a computer-readable storage medium, which stores a computer program. The computer program can be executed by the processor 11 to complete the method for detecting communication anomalies of a cryptographic machine provided in the present application.

[0060] The present application also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the method for detecting communication anomalies of a cryptographic machine provided in the present application.

[0061] See also Figure 3, is a flow chart of a method for detecting abnormal communication of a cryptographic machine provided in an embodiment of the present application, such as Figure 3 As shown, the method may include the following steps 310 to 330.

[0062] Step 310: Based on the negotiation logs between multiple cryptographic machines, filter out the cryptographic machine to be detected and generate a first event log; wherein the negotiation log records the initiator and receiver of the negotiation data, as well as the status of the negotiation data; the first event log indicates that the status of the negotiation data initiated by the cryptographic machine to be detected is abnormal.

[0063] Multiple cryptographic machines are deployed in the network environment, and each cryptographic machine is responsible for a network device in a corresponding area. During the communication process of network devices, under normal circumstances, the cryptographic machine in its area can encrypt the data packets sent by the network device.

[0064] When multiple cipher machines are started, different cipher machines can send negotiation data to each other, and accordingly, a negotiation log can be generated for the negotiation data, wherein the state of the negotiation data can be success or exception.

[0065] According to the initiator and receiver of the negotiation data recorded in the negotiation log, as well as the status of the negotiation data, the cipher machine whose initiated negotiation data is abnormal can be screened out as the cipher machine to be detected. Here, the cipher machine to be detected is a cipher machine that cannot communicate normally with other cipher machines.

[0066] After determining any cryptographic machine to be detected, it can be considered that a first event is triggered. The first event indicates that a cryptographic machine is detected that cannot communicate normally with other cryptographic machines. In this case, a first event log can be generated. The first event log can record the cryptographic machine identification of the cryptographic machine to be detected and the negotiation abnormality of the cryptographic machine to be detected.

[0067] Step 320: Based on the first event log and the communication log of the traffic data passing through each cipher machine, determine whether the cipher machine to be detected is the target cipher machine. If so, generate a second event log; wherein the communication log records the source cipher machine identifier, destination cipher machine identifier, data collection location, and encryption status of the traffic data; the second event log indicates that there is no encrypted traffic data at the output port of the target cipher machine.

[0068] For the cipher machine to be detected that cannot communicate normally with other cipher machines as indicated by the first event log, the cipher machine to be detected whose traffic data at the output port is not encrypted can be determined as the target cipher machine based on the communication log of the communication traffic of the cipher machine to be detected at the output port. Here, the target cipher machine is the cipher machine through which no encrypted data passes.

[0069] After confirming any target cipher machine, it can be considered that a second event is triggered. The second event indicates that it is detected that no encrypted traffic data passes through the cipher machine. In this case, a second event log can be generated. The second event log can record the cipher machine identification of the target cipher machine and the situation where no encrypted data passes through.

[0070] Step 330: Based on the second event log and the communication log, determine whether there is unencrypted data at the output port of the target cryptographic machine. If so, determine that the communication of the target cryptographic machine is abnormal.

[0071] For any target cryptographic machine through which no encrypted data passes as indicated by any second event log, it is possible to determine whether there is unencrypted data at the output port of the target cryptographic machine based on the communication log of the communication traffic at the output port of the target cryptographic machine. In this way, if there is unencrypted traffic data, it is determined that the target cryptographic machine has a communication abnormality problem.

[0072] Through the above content, with the help of logs containing rich information, in the scenario of multiple cipher machines, we can first screen out the cipher machines to be detected that cannot communicate normally with other cipher machines, and then determine whether the cipher machine to be detected is a target cipher machine through which no encrypted traffic data passes, and if the target cipher machine has unencrypted data passing through, determine that the target cipher machine has communication anomalies; in this case, we can effectively locate the cipher machine with communication anomalies in the scenario of multiple cipher machines, and avoid bypassing the cipher machine due to communication anomalies, resulting in sensitive data leakage or malicious attacks. This process can be automated, reducing the cost of manual investigation and improving the efficiency of detecting cipher machines with communication anomalies.

[0073] In one embodiment, before executing step 310, a negotiation log may be generated.

[0074] By setting data collection locations at the input and output ports of each cipher machine, when negotiation data is collected at any data collection location, the status (successful or abnormal), source cipher machine identifier and destination cipher machine identifier can be parsed from the negotiation data, and then a negotiation log can be generated based on the status, source cipher machine identifier and destination cipher machine identifier in the negotiation data.

[0075] The negotiation data includes negotiation request data and negotiation response data. The negotiation request data is the request data that the cipher machine initiates negotiation with other cipher machines; the negotiation response data is the data returned by the cipher machine in response to the negotiation request data initiated by other cipher machines.

[0076] In this case, the negotiation log may record the type of the negotiation data, which is negotiation request data or negotiation response data.

[0077] After the negotiation log is generated, the negotiation log can be put into the topic corresponding to the negotiation log in the Kafka message queue, so that the negotiation log can be read from the topic later.

[0078] Through this measure, when the cipher machines negotiate with each other, a negotiation log can be generated through the negotiation data, so that the cipher machine to be detected that cannot communicate with other cipher machines can be identified with the help of the negotiation log.

[0079] In one embodiment, when executing step 310 to determine the cipher machine to be detected, the negotiation logs belonging to each mutually negotiated cipher machine pair can be screened out according to the source cipher machine identifier and the destination cipher machine identifier recorded in the negotiation log. Here, the cipher machine pair includes two mutually negotiated cipher machines.

[0080] For the negotiation log of each cipher machine pair, it can be determined whether there is a cipher machine to be detected from the status of the negotiation data sent between the two cipher machines. Specifically, if there is a negotiation log indicating that the status of the negotiation data sent from the first cipher machine to the second cipher machine is successful, and there is another negotiation log indicating that the status of the negotiation data sent from the second cipher machine to the first cipher machine is abnormal, it can be explained that the reason for the abnormal negotiation between the second cipher machine and the first cipher machine lies in the second cipher machine. At this time, the second cipher machine can be used as the cipher machine to be detected.

[0081] Through this measure, the cipher machines to be detected that cannot communicate with other cipher machines can be limitedly screened out based on the negotiation log.

[0082] In one embodiment, see Figure 4 , is a flow chart of a method for generating a communication log provided in an embodiment of the present application, such as Figure 4 As shown, the method may include the following steps 410 to 430.

[0083] Step 410: When traffic data is collected from the preset data collection location, the preset cipher machine configuration table is searched with the source IP of the traffic data to determine the cipher machine identifier corresponding to the network segment to which the source IP belongs, as the source cipher machine identifier of the traffic data; wherein the cipher machine configuration table records the mapping relationship between multiple network segments and cipher machine identifiers.

[0084] This solution configures the mapping relationship between network segments and cipher machine identifiers for the network segments of the areas that each cipher machine is responsible for, and writes the mapping relationship into the cipher machine configuration table.

[0085] In this scheme, the data collection location can be set at the input and output ports of each cipher machine.

[0086] After collecting data traffic at any data collection location, the source IP can be parsed from the data traffic, and the cipher machine configuration table can be searched with the source IP to determine the network segment to which the source IP belongs in each table entry, and then the cipher machine identifier of the table entry where the network segment is located is used as the source cipher machine identifier of the traffic data. In this case, it means that the traffic data is sent by the network device in the area responsible for the cipher machine indicated by the active cipher machine identifier.

[0087] Step 420: Search the cipher machine configuration table according to the destination IP of the traffic data, and determine the cipher machine identifier corresponding to the network segment to which the destination IP belongs, as the destination cipher machine identifier of the traffic data.

[0088] The destination IP is parsed from the traffic data, and then the cipher machine configuration table is searched with the destination IP to determine the network segment to which the destination IP belongs in each table entry, and then the cipher machine identifier of the table entry where the network segment is located is used as the destination cipher machine identifier of the traffic data. In this case, it means that the traffic data is sent to the network device in the area that the cipher machine indicated by the destination cipher machine identifier is responsible for.

[0089] Step 430: Check the encryption status of the traffic data, and generate a communication log corresponding to the traffic data based on the encryption status, data collection location of the traffic data, source cipher machine identifier and destination cipher machine identifier.

[0090] The traffic data has a specific field for recording the encryption status of the traffic data, which can be encrypted or unencrypted. After obtaining the encryption field from the specific field, the communication log of the traffic data can be generated through the encryption field, the data collection location of the traffic data, the source cipher machine identifier and the destination cipher machine identifier. Of course, the communication log can also include other conventional content, such as the source IP and destination IP of the traffic data.

[0091] After the communication log is generated, the communication log can be put into the topic corresponding to the communication log in the Kafka message queue, so that the communication log can be read from the topic later.

[0092] Through this measure, a communication log containing richer content can be generated for the traffic data collected at each data collection location, so as to facilitate the subsequent detection task of abnormal communication of the cryptographic machine.

[0093] In one embodiment, see Figure 5 , provided in one embodiment of the present application Figure 3 The detailed flow chart of step 320 is as follows: Figure 5 As shown, when executing step 320 to determine the target cipher machine, the following steps 510 to 530 may be executed.

[0094] Step 510: parse the cryptographic machine identifier of the cryptographic machine to be detected from the first event log, and filter out the communication logs whose source cryptographic machine identifier matches the cryptographic machine identifier of the cryptographic machine to be detected.

[0095] After obtaining the first event log, the cipher machine identifier of the cipher machine to be detected can be parsed therefrom. From a large number of communication logs, the communication logs whose source cipher machine identifier matches the cipher machine identifier of the cipher machine to be detected are screened out.

[0096] Step 520: Determine whether there is a communication log in the filtered communication logs whose data collection location is the output port and whose encryption status is encrypted.

[0097] Step 530: If it does not exist, determine that the cryptographic machine to be detected is the target cryptographic machine.

[0098] According to the data collection position and encryption status in the screened communication log, it is determined whether there is a communication log whose data collection position is at the output port of the cipher machine to be detected and whose encryption status is encrypted.

[0099] On the one hand, if it exists, it means that there is encrypted traffic data at the output port of the cipher machine to be tested. In this case, the cipher machine to be tested still has encryption function, which means that the communication of the cipher machine to be tested is normal. On the other hand, if it does not exist, it means that there is no encrypted traffic data at the output port of the cipher machine to be tested. In this case, it can be determined that no encrypted data passes through the cipher machine to be tested, and it can be used as the target cipher machine.

[0100] Through the above measures, a logical judgment can be performed on the communication log that matches the cipher machine identifier of the cipher machine to be detected in the first event log, thereby effectively determining whether the cipher machine to be detected is the target cipher machine.

[0101] In one embodiment, see Figure 6 , provided in one embodiment of the present application Figure 3 The detailed flow chart of step 330 is as follows: Figure 6 As shown, when executing step 330 to determine whether the target cipher machine has communication abnormalities, the following steps 610 to 630 may be executed.

[0102] Step 610: parse the target cryptographic machine identifier from the second event log, and filter out the communication logs whose source cryptographic machine identifier matches the target cryptographic machine identifier.

[0103] After obtaining the second event log, the cipher machine identifier of the target cipher machine can be parsed therefrom. From a large number of communication logs, the communication logs whose source cipher machine identifier matches the cipher machine identifier of the target cipher machine are screened out.

[0104] Step 620: Determine whether there is a communication log in the filtered communication logs whose data collection location is the output port and whose encryption status is unencrypted.

[0105] Step 630: If present, determine that the target cryptographic machine has communication anomalies.

[0106] According to the data collection position and encryption status in the screened communication logs, it is determined whether there is a communication log whose data collection position is at the output port of the cipher machine to be detected and whose encryption status is unencrypted.

[0107] On the one hand, if it does not exist, it means that there is no traffic data passing through the output port of the target cipher machine. In this case, it cannot be determined that the target cipher machine does not encrypt the traffic data, and it is also impossible to determine that the target cipher machine has abnormal communication. At this time, the target cipher machine can be processed first, and the detection process can be executed after traffic data passes through the target cipher machine. On the other hand, if it exists, it means that unencrypted traffic data passes through the output port of the target cipher machine. In this case, it can be determined that the target cipher machine does not encrypt the traffic data. Combining the above judgments, it can be determined that the target cipher machine cannot communicate with other cipher machines, there is no encrypted traffic data at the output port of the target cipher machine, and the target cipher machine cannot encrypt the traffic data. Therefore, the target cipher machine is in an abnormal communication state.

[0108] Through the above measures, a logical judgment can be performed on the communication log that matches the cipher machine identifier of the cipher machine to be detected in the second event log, thereby effectively determining whether the target cipher machine has communication abnormalities.

[0109] In one embodiment, the communication log may record the organization information corresponding to the source cryptographic machine identification. In this case, the pre-configured cryptographic machine configuration table may record the organization information corresponding to each cryptographic machine identification. Here, the organization information may be the information of the cryptographic machine's operating enterprise, the information of the cryptographic machine's manufacturer, the enterprise information of the area that the cryptographic machine is responsible for, etc. In addition, the organization information may also include relevant information of the person in charge of the cryptographic machine (such as name, contact information, etc.).

[0110] Therefore, when generating a communication log, the organization information corresponding to the cryptographic machine identifier may be written into the communication log.

[0111] After determining that the target cryptographic machine has abnormal communication, an alarm message may be generated according to the cryptographic machine identification and organization information of the target cryptographic machine in the communication log. Here, the alarm message may indicate that the target cryptographic machine has abnormal communication.

[0112] Through this measure, alarm information of cryptographic machines with abnormal communication can be generated based on rich log information, so that cryptographic machines with abnormal communication can be reported in time.

[0113] The following is a specific example to illustrate the overall detection process:

[0114] The negotiation log between cipher machine 1 and cipher machine 2 includes a negotiation log in which the initiator is cipher machine 1, the receiver is cipher machine 2, and the status is normal, and a negotiation log in which the initiator is cipher machine 2, the receiver is cipher machine 1, and the status is abnormal.

[0115] At this point, it can be determined that cipher machine 2 cannot communicate with other cipher machines, is determined to be the cipher machine to be detected, and generates a first event log.

[0116] During the communication process, the source IP of a flow data is 1.1.1.1, and the destination IP is 1.1.1.2. The source IP belongs to the network segment corresponding to cipher machine 2, and the destination IP belongs to the network segment corresponding to cipher machine 3. In this case, a communication log is generated for the flow data, and the communication log records the source cipher machine identifier as the cipher machine identifier of cipher machine 2 and the destination cipher machine identifier as the cipher machine identifier of cipher machine 3. In addition, the data collection location of the flow data is at the output port of cipher machine 2, and the encryption status of the flow data is unencrypted.

[0117] According to the cipher machine identification of cipher machine 2 recorded in the first event log, the communication log whose source cipher machine identification is the cipher machine identification of cipher machine 2 is filtered.

[0118] After the communication logs are screened, it can be determined whether there is a communication log in the communication log whose data collection location is the output port of the cipher machine 2 and whose encryption state is encrypted.

[0119] At this time, there is no such communication log, and cipher machine 2 is determined as the target cipher machine, and then a second event log is generated.

[0120] According to the cipher machine identification of cipher machine 2 recorded in the second event log, the communication log whose source cipher machine identification is the cipher machine identification of cipher machine 2 is filtered.

[0121] After the communication logs are screened, it can be determined whether there are communication logs in which the data collection location is the output port of the cipher machine 2 and the encryption state is unencrypted.

[0122] The communication log previously generated for the traffic data with source IP 1.1.1.1 and destination IP 1.1.1.2 meets the conditions. Therefore, it can be determined that there is a communication abnormality problem with cryptographic machine 2.

[0123] Figure 7 is a block diagram of a device for detecting abnormal communication of a cryptographic machine according to an embodiment of the present invention, such as Figure 7 As shown, the device may include:

[0124] The first generating module 710 is used to screen out the cryptographic machine to be detected based on the negotiation logs between the multiple cryptographic machines, and generate a first event log; wherein the negotiation log records the initiator and the receiver of the negotiation data, and the state of the negotiation data; the first event log indicates that the state of the negotiation data initiated by the cryptographic machine to be detected is abnormal;

[0125] The second generating module 720 is used to determine whether the cipher machine to be detected is a target cipher machine based on the first event log and the communication log of the flow data passing through each cipher machine, and if so, generate a second event log; wherein the communication log records the source cipher machine identifier, the destination cipher machine identifier, the data collection location, and the encryption status of the flow data; the second event log indicates that there is no encrypted flow data at the output port of the target cipher machine;

[0126] The determination module 730 is used to determine whether there is unencrypted data at the output port of the target cryptographic machine based on the second event log and the communication log. If so, it is determined that the communication of the target cryptographic machine is abnormal.

[0127] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method for detecting abnormal communication of the cryptographic machine, and will not be repeated here.

[0128] In several embodiments provided in the present application, the disclosed devices and methods may also be implemented in other ways. The device embodiments described above are merely schematic, for example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram may represent a module, a program segment or a part of a code, and a module, a program segment or a part of a code contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they may sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or the flowchart, and the combination of boxes in the block diagram and / or the flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0129] In addition, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0130] If the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, and other media that can store program codes.

Claims

1. A method for detecting abnormal communication of a cryptographic machine, characterized in that: include: Based on the negotiation logs between multiple cryptographic machines, the cryptographic machine to be detected is screened out, and a first event log is generated; wherein the negotiation log records the initiator and receiver of the negotiation data, and the status of the negotiation data; the first event log indicates that the status of the negotiation data initiated by the cryptographic machine to be detected is abnormal; According to the first event log and the communication log of the flow data passing through each cipher machine, it is determined whether the cipher machine to be detected is the target cipher machine, and if so, a second event log is generated; wherein the communication log records the source cipher machine identification, the destination cipher machine identification, the data collection location, and the encryption status of the flow data; the second event log indicates that there is no encrypted flow data at the output port of the target cipher machine; Based on the second event log and the communication log, determine whether there is unencrypted data at the output port of the target cryptographic machine. If so, determine that the communication of the target cryptographic machine is abnormal.

2. The method according to claim 1, characterized in that Before screening out the cryptographic machines to be detected based on the negotiation logs between the multiple cryptographic machines and generating the first event log, the method further includes: When the negotiation data is collected, a negotiation log is generated according to the state, source cipher machine identifier and target cipher machine identifier in the negotiation data.

3. The method according to claim 1, characterized in that The method of screening out the cryptographic machines to be detected based on the negotiation logs between the multiple cryptographic machines includes: If there is a negotiation log indicating that the status of the negotiation data sent from the first cryptographic machine to the second cryptographic machine is successful, and there is a negotiation log indicating that the status of the negotiation data sent from the second cryptographic machine to the first cryptographic machine is abnormal, the second cryptographic machine is used as the cryptographic machine to be detected.

4. The method according to claim 1, characterized in that: The communication log generation step includes: When flow data is collected from a preset data collection location, the preset cipher machine configuration table is searched with the source IP of the flow data to determine the cipher machine identifier corresponding to the network segment to which the source IP belongs, as the source cipher machine identifier of the flow data; wherein the cipher machine configuration table records the mapping relationship between multiple network segments and cipher machine identifiers; Search the cipher machine configuration table according to the destination IP of the traffic data, determine the cipher machine identifier corresponding to the network segment to which the destination IP belongs, and use it as the destination cipher machine identifier of the traffic data; Check the encryption status of the traffic data, and generate a communication log corresponding to the traffic data based on the encryption status, the data collection location of the traffic data, the source cipher machine identifier and the destination cipher machine identifier.

5. The method according to claim 1, characterized in that The step of judging whether the cryptographic machine to be detected is a target cryptographic machine based on the first event log and the communication log of the flow data passing through each cryptographic machine includes: Parsing the cryptographic machine identifier of the cryptographic machine to be detected from the first event log, and filtering out the communication logs whose source cryptographic machine identifier matches the cryptographic machine identifier of the cryptographic machine to be detected; Determine whether there is a communication log in the filtered communication logs whose data collection location is an output port and whose encryption state is encrypted; If not present, it is determined that the cryptographic machine to be detected is the target cryptographic machine.

6. The method according to claim 1, characterized in that The determining, based on the second event log and the communication log, whether there is unencrypted data at the output port of the target cryptographic machine, and if so, determining that the communication of the target cryptographic machine is abnormal, includes: Parsing the target cryptographic machine identifier of the target cryptographic machine from the second event log, and filtering out the communication logs whose source cryptographic machine identifier matches the target cryptographic machine identifier; Determine whether there is a communication log in the filtered communication logs whose data collection location is the output port and whose encryption status is unencrypted; If so, it is determined that the target cryptographic machine has communication abnormalities.

7. The method according to claim 1, characterized in that The communication log records the organization information corresponding to the source cipher machine identification; After determining that the target cryptographic machine has abnormal communication, the method further includes: Generate an alarm message based on the cipher machine identification and organization information of the target cipher machine in the communication log; wherein the alarm message indicates that the target cipher machine has abnormal communication.

8. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing processor-executable instructions; Wherein, the processor is configured to execute the method for detecting abnormal communication of a cryptographic machine as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that: The storage medium stores a computer program, and the computer program can be executed by a processor to complete the method for detecting abnormal communication of a cryptographic machine as described in any one of claims 1-7.

10. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the method for detecting abnormal communication of a cryptographic machine as described in any one of claims 1 to 7 is implemented.

Images