A graph storage method and system for network behavior data

Abstract

The application discloses a graph storage method and system for network behavior data, and relates to the field of computer network security. The application normalizes network traffic logs, stores all types of data in a graph mode, so as to quickly extract the correlation between networks, and optimizes the network correlation query efficiency from multiple angles according to the query principle of the JanusGraph distributed graph database. The application uses the SDDQN model with operator action verification to enhance the learning of the operator chain formation state step, uses the query time as the feedback value to adjust the formation step, creates the IDRC cache strategy on the query cache strategy, and realizes the synchronous update of the memory and the database. The application solves the problem of inefficient query of internal correlation data of massive, multi-dimensional and heterogeneous network situation behavior data, and helps users to better observe and understand data through a visual interface.

Description

TECHNICAL FIELD

[0001] The present application provides a graph storage method for network behavior data, which combines a graph model to capture the association mode and communication rule in network data, and constructs a storage system for massive, multi-dimensional and heterogeneous network behavior data. The present application relates to the field of computer network security and is used to solve the problem of behavior monitoring of heterogeneous network data. BACKGROUND

[0002] In recent years, the Internet has gradually become popular, and the network scale has been increasing. With the expansion of network scale and business, the heterogeneous characteristics of the network are becoming more and more prominent, and how to store network data to monitor network behavior has become the first difficulty to be solved. At present, many network security manufacturers have paid attention to the problem of network data storage, and have developed network behavior data collection and storage systems, forming their own technical barriers. However, the multi-device network data collected by each manufacturer has the characteristics of large scale, multi-dimensionality, diversity, different formats, fragmentation, etc., and it is difficult to understand the operation of the network, extract relevant data, analyze event trajectories, etc. through these data, which has a high requirement for the prior knowledge of the operator and the mastery of the data. In addition, with the increasing of network traffic and log data, it is necessary to achieve the requirements of retaining data time length and meeting the requirements of efficient query of associated data, low latency under large data volume, which requires the database to have more efficient information processing capability.

[0003] In terms of storage, the traffic and logs monitored from the network are often unstructured data. In order to analyze and associate the network situation behavior data in detail, security manufacturers have developed various traffic and log analysis platforms to split the data into fields for storage, which is convenient for analysts to conduct deep information mining. Generally, structured data is stored in a relational database (commonly known as Oracle, MySQL, etc.). The relational database has been supported for more than ten years, and the community is rich and the documents are comprehensive, which meets the development needs of most security manufacturers' applications. However, with the increasing demand for application business types, relational storage has exposed some defects, such as only supporting fixed table mode, poor scalability of attributes, unable to update field data at any time during application, having to perform a SQL JOIN operation each time for association relationship query, and being not friendly to the storage of massive data. The rise of NoSQL (Not Only SQL) database has solved the problem of storing massive heterogeneous data.

[0004] The NoSQL database has multiple data storage modes such as document format, graph format, object format and xml format, has strong horizontal expansion capability, supports distributed cluster storage, automatic backup and fault tolerance, and can overcome the problems of insufficient storage space and high server pressure. If the relational database is more suitable for user-oriented front-end business systems, the non-relational database is more suitable for data management and data analysis background business systems. Among them, the graph database as a kind of NoSQL database is a storage mode for "graph" data structure, and its storage structure is more in line with the characteristics of highly correlated network situation behavior data, and has stronger correlation data extraction capability. Therefore, the method of graph model can often capture and display the correlation mode and communication law in network data more quickly.

[0005] For the storage of network situation behavior data, the security analysis department is most concerned about whether it can store massive data and whether it can quickly extract network behavior entities and associated data. If the internal correlation structure of network situation behavior data can be mapped to a distributed graph database for storage, it will be an important way to solve the above two network behavior access problems. Although a large number of graph data systems have been developed in the current academic and industrial circles, each system has its advantages and disadvantages and use scenarios. For example, the most widely used Neo4j graph database cannot solve the problem of large data storage; the new TigerGraph with the ability to store massive data is completely closed source and commercialized, and cannot adjust the source code according to the demand; some graph databases have distributed query capability, but do not have the original graph query speed. Therefore, according to the business requirements, the appropriate graph database is selected, and the corresponding defects are improved, which is of great significance to solve the storage problem of network data and the big data analysis challenge of network space security. SUMMARY

[0006] The purpose of the present application is to provide a graph storage method and system for network behavior data. In order to solve the problem of inefficient query of internal associated data of massive, multi-dimensional and heterogeneous network situation behavior data, the present application normalizes network flow logs, stores all types of data in the form of graph mode, so as to quickly extract the correlation between networks, and optimizes the network correlation query efficiency from multiple angles according to the query principle of JanusGraph distributed graph database.

[0007] To achieve the above purpose, the specific technical scheme adopted by the present application is:

[0008] A graph storage method for network behavior data, comprising the following steps:

[0009] 1) Data collection: Collecting traffic and log data from security vendors, completing preliminary integration and structured parsing of data via security vendors, and sending to message queue;

[0010] 2) Data dump: Obtaining data from message queue and performing data preprocessing, persistently storing preprocessed data and establishing index;

[0011] 3) Graph database storage: Storing data stored in step 2) according to four types of single machine behavior, network stream, network basic application, and network security application, formulating four types of graph mode storage structures, and storing in JanusGraph distributed graph database;

[0012] 4) Back-end data processing: For JanusGraph distributed graph database, first embed SDDQN-based graph database query execution strategy and ID replacement-based query cache matching strategy, wherein the SDDQN-based graph database query execution strategy refers to constructing a DDQN query chain optimization algorithm SDDQN for a query operator Step chain based on JanusGraph-Server retrieval engine, and using the SDDQN as a query execution strategy; the ID replacement-based query cache matching strategy refers to constructing a query cache matching storage strategy IDRC using ID instead of nodes and edges in the adjacency list based on the unique ID markers of nodes, edges, and properties in the adjacency list physical storage of the database level cache of the JanusGraph distributed graph database; then replacing low-frequency cache through the cache replacement strategy to optimize the cache; finally, for the four types of graph mode storage structures, encapsulate the standardized statement query interface of basic query, complex query, and graph computation query, and extract the graph computation parameters for network behavior description and encapsulate as network graph calling interface;

[0013] 5) User service: Creating a dynamic interactive visualization interface for users, calling the query interface and network graph calling interface, and providing network behavior data association query and network behavior feature query for users.

[0014] Preferably, in step 1), the JSON format is pushed into the Kafka channel through the proxy interface of the vendor data, and sent to the message queue.

[0015] Preferably, in step 2), the data preprocessing includes three steps of field normalization, repeated log removal, and meaningless data elimination.

[0016] Preferably, the method for persistently storing and indexing the preprocessed data in step 2) is as follows: Hadoop HDFS is used as a distributed storage persistent layer, Hbase is used as a data management layer, Elasticsearch is embedded as an indexing tool to provide full-text indexing function for the upper layer JanusGraph, and Zookeeper cluster is used to guarantee data consistency scheduling.

[0017] Preferably, in step 4), SDDQN intercepts the Step chain of the parsing operator of JanusGraph-Server retrieval engine, uses query time as feedback, and learns the optimal combination strategy between Steps in the long execution operator Step chain by training the action value approximation function under the condition of data attribute and operator combination, so as to reduce the number of intermediate node hits during association query and improve query speed.

[0018] Preferably, in step 4), SDDQN includes the following four algorithm modules:

[0019] The operator Step chain cutting module is used to split and mark the sub-operator Step chain containing the execution scope, and remind that the operator state cannot be transferred across the mark during state transition;

[0020] The operator feature extraction module is used to normalize each operator into a five-tuple composed of the serial number of the current operator, the operator function name, the parameter name, the parameter value and the limited range;

[0021] The DDQN decision maker module is used for DDQN training and decision making. By constructing an experience replay pool and storing the current and historical samples of the interaction between the operator Step chain and JanusGraph-Server, the action value selection and behavior evaluation are trained by two neural network structures of DDQN respectively. The convergence speed is improved by using the ε-greedy algorithm;

[0022] The operator logic restoration and verification module is used to perform action verification after each step Action selection in DDQN, and to perform operator Step chain verification based on the Standard Verification Strategy strategy of JanusGraph-Server after all decision executions are completed. After verification, finalEndStep is added to the tail of the operator Step chain, and the operator Step chain is locked to traverse the database node. Finally, filtering operation and database query are performed for different operators.

[0023] Preferably, the specific functions of the DDQN decision maker module are as follows:

[0024] Before training the DDQN, an initial state is set, and the initial state contains an empty list Lnew L, a list of all operators in the query statement steps ;

[0025] When an action a is executed each time t At that time, from L steps Select an operator to add to L new In the list, the L new A list of selected operators in a list is considered as a state s. t All states constitute the state set S, when L new L steps When the two lists have the same length, s t The process has reached a halted state;

[0026] During each state transition, the action of the next selected operator is treated as an action 'a'. t And based on the state-action value function, i.e., the ε-greedy algorithm, selects the action a that should be executed. t ;

[0027] Perform an action check on the selected operator. If the selected operator is one of the location operator SelectStep, the matching operator MatchStep, the output operator MapStep, or the operator that carries conditions during chain splitting, check whether the variables contained in the current state have been placed into the quintuple of the existing operators in the chain. If not, the action is invalidated, and the state-action value function is re-executed to select a new action.

[0028] When the selected operator is one of the HasStep / WhereStep condition constraint operators or the AsStep initialization operator, it is determined whether the operator is adjacent to the node operator. If they are not adjacent, the operator is invalid.

[0029] Preferably, the action to be performed, a, is selected based on the state-action value function. t The steps include:

[0030] Each time you choose action a t At that time, the state-action value function pre-determines the current state s. t Check if all operators have been used. If there are still unused operators, and a t If the action is verified, then the feedback value r is set. t =0, and adopt the currently selected action to proceed to the next state;

[0031] If the operator is not used, and a t If the action verification fails, then let r be... t =-1, next time in the current state s t The operator will no longer be selected, and the process will directly enter the termination state;

[0032] If all operators have been selected and the operator Step chain validity check passes, the query of the complete operator Step chain is executed directly in the environment, set r t = λexp(-τ), where λ is a hyperparameter used to adjust the influence of the feedback value, and τ is the length of the database query time. t

[0033] If all operators have been used and the operator Step chain validity check passes, when the execution of the operator Step chain query takes time τ that exceeds the upper limit of the query time τ0, set r t = -1.

[0034] Preferably, the DDQN adopts a fully connected neural network, including 3 hidden layers containing 128, 64 and 32 neurons respectively, and selects the Softmax activation function and the gradient descent Adam algorithm as the training optimizer to iteratively update the weight parameters.

[0035] Preferably, the cache matching rule executed by the ID replacement-based query cache matching strategy in step 4) is as follows:

[0036] (1) Set a temporary variable result <list>, for storing the data obtained from the query;

[0037] (2) Obtain the queries array composed of all key values in the query cache set, and loop to take out each query statement query-key, and judge whether there is a string matching the full byte of the current user query statement query. If there is, terminate the loop, record the current query-key value and perform step (3). If the last value is not matched successfully, directly execute step (6);

[0038] (3) According to the query-key object obtained by matching, take out the corresponding ValueObject object, and perform an increment operation on the use time attribute of the object. Let lastUseDate equal the current time, and get the Boolean value of isSubGraph. If it is true, proceed to step (4), otherwise proceed to step (5);

[0039] (4) According to the ValueObject object, return the subgraph IDs list, traverse the list once to restore the node, edge, and attribute corresponding values, generate a subgraph list, assign the list to the result variable, and execute step (7)

[0040] (5) According to the ValueObject object, return the subgraph shortValue value and assign it to result, and then execute step (7);

[0041] (6) If the matching fails, enter the normal database query operation, update the memory cache, assign the query result to result, and enter step (7);

[0042] (7) Return the result list, complete all steps and jump out.

[0043] Preferably, the cache replacement strategy in step 4) is as follows:

[0044] First, 30% of the space in the cache is allocated for storing low-frequency recurring statements, and the remaining space is used for storing hot statements;

[0045] Then, when a statement is queried, it is first stored in the hot statement area; and records with less than 2 times of use within 1 day in the hot statement area are treated as accidental records without the need for caching, and are directly removed from the cache;

[0046] Finally, statements with less than 10 times of use within 1 week are treated as low-frequency recurring statements and are placed in the low-frequency recurring statement area. When the cache is too large or the memory is about to overflow, the cache in the low-frequency recurring statement area is directly cleared, and the old statements in the hot cache area are replaced according to the LFU strategy to achieve optimal cache.

[0047] Preferably, the basic query in step 4) includes attribute query, statistical query, grouping query, node query, relationship query and deep matching query; and the complex query includes long path query and traversal query.

[0048] Preferably, the graph calculation parameters in step 4) include network behavior graph average degree, network behavior graph node bias, subgraph number and maximum subgraph connectivity rate and one-way connection maximum depth.

[0049] Preferably, the visualization interface in step 5) includes a basic query area, an advanced setting area, a network relationship graph visualization area, a result record area and a network behavior statistics area.

[0050] A graph storage system for network behavior data, comprising a memory and a processor, wherein a computer program is stored on the memory, and the processor implements the steps of the above method when executing the program.

[0051] The technical effects achieved by the present application are as follows:

[0052] The present application uses a graph model to store network behavior data, and can associate related objects together through edges or links to directly show the relationship between data objects. The present application regards the formation of an operator chain as a Markov process, and uses an SDDQN model with operator action verification to perform reinforcement learning on the formation state steps of the operator chain, so as to adjust the formation steps by using the query time as a feedback value. An IDRC cache strategy is created on the query cache strategy, and the memory and the database are synchronously updated. The cache replacement strategy designed in the present application can be based on the query occurrence time, the query occurrence frequency and the proportional storage, and the intelligent update of the cache is realized. The present application builds a service connection layer and a data visualization layer display system on this basis, completes the integrated service of the network data graph query system for users, and helps users to better observe data and understand data. The present application provides important technical support for future network application behavior research based on evolution characteristics, malicious behavior research based on internal association anomaly discovery and other directions. BRIEF DESCRIPTION OF DRAWINGS

[0053] Figure 1 is the overall architecture diagram of the graph storage method for network behavior data in the present application.

[0054] Figures 2A-2D is a knowledge graph representation schematic diagram of four types of network behavior data; wherein Figure 2A is a single machine behavior data graph structure, Figure 2B is a network flow data graph structure, Figure 2C is a network basic application data graph structure, Figure 2D is a network security application data graph structure.

[0055] Figure 3 is the SDDQN query execution strategy architecture diagram.

[0056] Figure 4 is the flow of cache replacement strategy.

[0057] Figure 5 is the global visualization interface display of the system of the application.

[0058] Figure 6 is the 5-degree depth query display diagram of the VPN login log of the user gryffindor in the system of the application.

[0059] Figure 7 is the effect display diagram of the first 500 nodes of the FTP protocol interaction flow generated on March 1 in the query of the system of the application.

[0060] Figure 8 is the interface diagram of the advanced settings-feature calculation parameter selection area in the system of the application.

[0061] Figure 9 is an 800-node diagram example of five network behavior protocols in the system of the application; wherein the protocols are (a) SMTP diagram, (b) DNS diagram, (c) FTP diagram, (d) Telnet diagram and (e) HTTP diagram in turn.

[0062] Figure 10 is the comparison test diagram of the query efficiency before and after the strategy optimization Q1-Q12; wherein (a) is the test result of 1-day data, (b) is the test result of 4-day data, and (c) is the test result of 7-day data. DETAILED DESCRIPTION

[0063] In order to make the person skilled in the art better understand the technical solutions in the embodiments of the application, and make the purpose, characteristics and advantages of the application more obvious and easy to understand, the technical cores in the application are further described in detail below in combination with the drawings. It should be understood that the specific embodiments described herein are only used to explain the application and not to limit the application.

[0064] The application proposes a graph storage method for network behavior data, and based on the method, a storage, association and query integrated system for network behavior data, i.e. a graph storage system for network behavior data, is constructed. The overall idea of the method and the system is to uniformly store data in four types of graph pattern structures, so as to facilitate users to quickly extract the association relationship between networks, and at the same time, to optimize the query speed from the aspects of graph query interception and query cache, and finally to realize a visual system for user convenient interaction.

[0065] The overall architecture of the application is shown in Figure 1 The specific steps of the method are described in detail as follows:

[0066] (1)Data collection

[0067] The original network flow of each monitoring interface is obtained through the mirror of the shunt, and the original flow and log are obtained by cooperating with the security vendor. The vendor performs preliminary analysis on the data, completes the preliminary integration and structured analysis of the data, that is, all fields have been processed into the field format of key-value pair. These data are pushed into the Kafka channel in JSON format through the proxy interface of the vendor data.

[0068] (2)Data dump

[0069] The real-time transmission data is obtained from the Kafka message queue, and data preprocessing is performed; then HDFS of Hadoop is used as a distributed storage persistent layer, Hbase is used as a data management layer, Elasticsearch is embedded as an index tool to provide full-text index function for the upper JanusGraph, and finally, Zookeeper cluster is used to guarantee data consistency scheduling.

[0070] Data preprocessing includes three steps of field normalization, repeated log removal and meaningless data elimination, wherein:

[0071] ①The field normalization method is mainly through the construction of the method of extracting and dictionary matching by rules, for example, the expression of source ip has: src_ip, source_ip, client_ip, start_ip, etc. First, the string containing "_ip$" is matched by regular expression, and then the prefix is obtained to judge whether it is in the [src, source, client, start…] array. If it is matched, it is unified as the field srcIP.

[0072] ②For repeated logs, it needs to be classified: some repeated logs are full records of logs, for example, firewall logs, the same user accessing the same port leaves the same log content in the firewall, and all other fields are the same except time. In this case, the time in the first log record can be set as an array format, and only one time attribute is added for each new record. Some repeated logs are redundant logs and do not need to be kept, for example, a large number of repeated logs may be generated in a short time when an event triggers an alarm. At this time, the relevance between these logs needs to be judged, and the logs belonging to the same event are fused and merged into one data.

[0073] ③For logs with missing attributes, if the missing is the main field (the field marked as unique or the field marked as index attribute when the main graph schema is constructed), the data is directly deleted; if the missing is other fields, it can be ignored because the empty field of the graph database does not occupy space.

[0074] (3) Graph database storage

[0075] According to the network behavior characteristics and the construction principle of the knowledge graph, the graph node attribute and label, and the edge attribute category are designed, indexes are set according to the actual data situation, data meeting the network topology structure are stored into the database, and specifically, according to four types of behavior data of single machine behavior, network flow, network basic application and network security application, the graph mode storage structure of the four types of data is formulated, as shown in Figures 2A-2D The data is classified and stored into the JanusGraph distributed graph database according to the corresponding graph mode, the extraction speed of the internal association relationship of the network graph is faster than that of the traditional Elasticsearch (ES) storage by one order of magnitude, so that the rapid extraction of the network association relationship is realized, and the network data backtracking ability is improved.

[0076] (4) Backend data processing

[0077] The SDDQN-based graph database query execution strategy is embedded, the query cache matching strategy based on ID replacement is embedded, the cache consistency and replacement rules are replaced, typical network association relationship query statements and graph parameter calculation statements are encapsulated as interfaces, and the database content is retrieved according to the front-end user input parameters.

[0078] 1) SDDQN-based graph database query execution strategy

[0079] In the query language Gremlin of JanusGraph, when each Gremlin statement is executed, the statement object is first disassembled and reassembled, different statements are split into different operators, and the operator steps Step formed are stored as an operator Step chain. The DDQN (Deep Double Q-Network) model SDDQN designed for the query operator Step chain is inserted into the JanusGraph-Server retrieval engine, and the execution architecture after introducing the model is as shown in Figure 3 . Figure 3 The engine optimization strategy mentioned in the prior art before SDDNQ execution is a self-provided strategy of JanusGraph-Server retrieval engine, including Count Strategy, Repeat Unroll Strategy and the like, having functions of operator expansion or merging, operator correctness verification and the like, this link can standardize the operator for subsequent processing, so it is used before the operator enhancement model. SDDQN mainly includes operator Step chain cutting, operator feature selection, DDQN decision maker and operator logic restoration and verification algorithm modules.

[0080] ①Operator Step chain cutting, mainly for the sub-operator Step chain containing the execution scope to mark the cutting, remind the operator state transfer cannot cross the mark transfer. For example, LoopStep loop operator, IfElseThenStep conditional selection operator, they themselves form a layer of sub-chain barrier, in order to enhance learning using cutting mark to place barrier inside and outside the operator attribute mutual pollution.

[0081] ②Operator feature extraction, in order to facilitate the management of neural network model data input format, each operator is standardized to five tuple <StepNumber, StepName, ParamType, ParamValue, Scope>, respectively represents the current operator serial number, operator function name, parameter name, parameter value and limited range.

[0082] ③DDQN decision maker, used for DDQN training and decision. By building experience replay pool, the current and historical samples of agent and environment interaction are stored therein, through experience pool random sampling training, the problem of lack of large number of artificial marking samples in deep learning is solved; action value selection and behavior evaluation are trained by using two neural network structures respectively; using ε-greedy algorithm, the convergence speed is improved. Through this model, the speed of operator Step chain can be constructed than the initial operator Step chain.

[0083] ④Operator logic restoration and verification. After each step Action selection in DDQN, action verification is still needed. In addition, after all decision execution is completed, operator Step chain verification is needed based on JanusGraph-Server's Standard VerificationStrategy standard verification strategy, after verification, finalEndStep is added to the tail of operator Step chain and lock operator Step chain traverses database node, and different operators are filtered and queried.

[0084] Specifically, in the implementation of SDDQN, the operator Step chain is regarded as the agent, and the environment is JanusGraph-Server retrieval engine. Before DDQN model training, an initial state needs to be set, which is an empty list L new , and a list L steps composed of all operators in the query statement. The executor executes an action a t each time, needs to select an operator (operator serial number is unique) from L steps to join L new list, list L new changes. The list of selected operators in L new list is called a state s t , all states form a state set S, when L new .length = L steps .length, s t reaches the abort state.

[0085] Each time the state is transferred, the next operator to be connected needs to be selected as an action a t , all actions form an action set A, but there are also some invalid a t in A. Each a t is selected by a state-action value function, and the a t to be executed is selected according to the ε-greedy algorithm first, and then an action verification is performed after the selection, when the selected operator is one of the functional operators such as the positioning operator SelectStep, the matching operator MatchStep, the output operator MapStep, and the chain partitioning operator carrying conditions, it is necessary to judge whether the variables contained in the current state have been placed in the five-tuple ParamValue of the existing operator in the chain, otherwise the behavior is invalid, and a new behavior needs to be selected by the state-action value function; in addition, when the selected operator is the HasStep / WhereStep condition limiting operator or the AsStep initialization operator, it is necessary to judge whether these operators are adjacent to the node operator, and if not, the behavior is invalid.

[0086] The feedback value r t is set to four categories. First, each time an action a t is performed, the state-action value function will first judge whether all operators have been used in the current state s t , if there are operators that have not been used, and a t does not pass the action verification described above, then set r t = 0, and adopt the current selected action to proceed to the next state; if the operator has not been used, but a t does not pass the action verification, then set r t = -1, and do not select this operator in the current state next time, and directly enter the termination state; if all operators have been selected in the current s t and the operator Step chain validity verification is passed, then the query of the complete operator Step chain is directly executed in the environment, assuming that the database query time length is τ, in theory, the longer the query time, the lower the feedback score should be, and the shorter the time, the larger the feedback score should be, therefore the feedback value is set to the inverse function of the time r t = λexp(-τ). Wherein, λ is a hyper parameter for adjusting the influence of feedback value, so that the feedback value grows with time τ in the opposite number; if all are used and the operator Step chain validity check is passed, when the operator Step chain query is executed, the time τ is too long, which exceeds the upper limit of query time τ0, then set r t = -1, indicating that the current operator Step chain execution timeout is not a good decision, so a negative feedback value is needed.

[0087] In the present application, since the five-tuple extraction is performed on the input state, and the input is not as complex as the image, the fully connected neural network is adopted. The construction of the fully connected network needs to consider the hierarchy, the number of neurons setting, the more the number of layers, the better the data abstraction ability and function approximation effect, but overfitting is easy to occur; the more the number of neurons, the more the parameter dimension increases, which also lengthens the training time, so a trade-off needs to be made. The present application sets 3 hidden layers, respectively containing 128, 64 and 32 neurons, and selects the Softmax activation function, and the gradient descent Adam algorithm as the training optimizer to iteratively update the weight parameters, the learning rate is set to 0.00025, and the exploration rate in the greedy method is set to ε = 0.1. Other hyper parameters also need to be adjusted and optimized for many times, in order to ensure that the experience pool D can reflect the sample diversity and ensure the training effectiveness, the upper limit of the capacity can be set to D length = 50000, generally the sample of the experience pool reaches 1 / 20 of the total capacity, and then the training can be started, so the accumulation parameter is set to m = 2500, and the update frequency of the target network is set to C = 5000 action steps.

[0088] 2) Embedding ID replacement-based query cache matching strategy

[0089] JanusGraph has multiple cache layers, which are transaction-level cache, database-level cache and external storage-level cache. The present application designs an ID replacement-based matching storage strategy for the database-level cache strategy, which is called IDReplace Cache Strategy (IDRC).

[0090] In JanusGraph, each node, edge and attribute has a unique ID mark, if the ID is used instead of the node and edge in the adjacency list, each ID is only 64 bits, which will greatly reduce the space occupied by the query subgraph, and all IDs can directly locate the data in the graph database without performing a subgraph iteration query process, thus playing a cache role and speeding up the query. In order to prepare for the subsequent cache replacement strategy, the creation time, last use time and use frequency are also added to the query conditions, and a single cache query data structure designed at present is as Figure 3 shown.

[0091] Meanwhile, according to the data structure, the application realizes new cache matching rules, and the steps are as follows:

[0092] First step: setting temporary variable result <list>, for storing the data obtained by the query.

[0093] Second step: get the queries array composed of all key values in the query cache collection, loop out each query statement query-key, judge whether there is a string matching the current user query statement query full byte, if it exists, terminate the loop, record the current query-key value and perform the third step; if the last value is not matched successfully, execute the sixth step directly.

[0094] Third step: according to the matched query-key object, take out the corresponding ValueObject object, and execute the plus operation on the use time attribute in the object; let lastUseDate equal to the current time; and get the isSubGraph boolean value, if true, go to the fourth step, otherwise go to the fifth step.

[0095] Fourth step: according to the ValueObject object, return the subgraph IDs list, traverse the list once to restore the node, edge and attribute corresponding values, generate the subgraph list, assign the list to the result variable, and execute the seventh step;

[0096] Fifth step: according to the ValueObject object, return the subgraph shortValue value and assign it to result, then execute the seventh step.

[0097] Sixth step: if the matching fails, enter the normal database query operation and update the memory cache, assign the query result to result, and go to the next step.

[0098] Seventh step: return the result list, complete all steps and jump out.

[0099] 3) Cache replacement strategy

[0100] Each query key-value pair in the cache has a corresponding use time and use frequency record. Since not all caches are high-frequency caches, for occasional queries and low-frequency recurring statements, they should be replaced in time to achieve optimal cache.

[0101] The present application specifies the following strategy to replace the low frequency cache. First, 30% of the space is separated from the cache for storing low frequency recurrence statements, and the remaining space is used to store hot statements. When there is a statement query, it is first stored in the hot statement area, and the records with less than 2 times of use within 1 day in the hot statement area are directly eliminated from the cache as sporadic records without the need for caching; for the statements with less than 10 times of use within 1 week, they are regarded as low recurrence statements and are placed in the low frequency recurrence statement area. When the cache is too large or the memory is about to overflow, the cache in the low frequency recurrence area is directly cleared, and the old statements are replaced in time according to the LFU (Least frequently used) strategy to achieve the optimal cache. The cache replacement strategy is as shown in Figure 4 .

[0102] 4) encapsulation of network behavior graph pattern information extraction

[0103] In order to fully utilize the advantages of graph pattern storage for network behavior data extraction, and to provide graph computing support for subsequent network event anomaly analysis, the present application encapsulates the standardized statements of basic queries, complex queries and graph computing queries on the basis of the designed graph pattern. Among them, the basic query is the query operation of related graph nodes, relations and attributes, and the basic relational query such as attribute query, statistical query, grouping query, node query, relation query and depth matching query is encapsulated as an interface. The complex query is generally divided into two types of long path query and traversal query, and the present application optimizes the complex statements by moving a limited number of feature nodes forward, using sorting, using other expression methods instead of match statements to avoid Cartesian product calculation, reasonably using indexes, avoiding using or or expression operations in the where statement to avoid full table comparison, using numerical information fields instead of character type fields to speed up comparison, avoiding establishing temporary graphs to reduce resource consumption and the like.

[0104] 5) encapsulation of network information graph computing pattern extraction

[0105] According to common graph features, the present application extracts some graph computing parameters that can be used for network behavior description and encapsulates them as a network graph calling interface, so as to lay a foundation for subsequent quantitative analysis of network flow behavior. The graph computing parameters applied in the present application are:

[0106] ① Network behavior graph average degree: used to measure the degree of complex association within a network. Select a network subgraph, if the value of this parameter is higher, it means that the interaction behavior between hosts in the subgraph is closer, and the network is more active, otherwise the average degree is lower, which means that the internal association relationship of the network is sparser.

[0107] ② Network behavior graph node bias: this parameter refers to the nodes in a network that only contain in-degree in The proportion of all nodes N, or only the out-degree of the node out The proportion of all nodes N, or the out-degree and in-degree of the node node both The proportion of all nodes N. Bias is generally used to find the direction of the initiation, receiving state of the interaction flow between hosts in the current network.

[0108] ③The number of subgraphs and the maximum subgraph connectivity rate: the network is regarded as an undirected graph, and the number of subgraphs is to solve the number of connected graphs M in this undirected graph conn , and the subgraph connectivity rate is to solve the proportion of the nodes contained in the maximum connected subgraph of the current network to the total number of nodes. The number of connected subgraphs reflects the dispersion of the current network, and the larger the value, the more isolated networks there are, and the smaller the value, the stronger the network connectivity. The larger the maximum subgraph connectivity rate, the more interactive large graphs exist in the network.

[0109] ④The maximum depth of one-way connection: this parameter refers to the number of single-direction maximum connection hosts in a network, which can describe the propagation characteristics of the network.

[0110] (5) User service

[0111] The network graph behavior backtracking and calculation results are simply visualized. The visualization system uses front-end and back-end separation development, and the front-end is deployed through Nginx. The visualization interface is as shown in Figure 5 . From top to bottom and from left to right, the following partition functions are arranged in order:

[0112] 1) Basic query area: use Gremlin operation language to directly query in the database query box, and return the backtracking relationship subgraph of the relevant nodes and edges.

[0113] 2) Advanced setting area: call the network behavior graph feature calculation interface to calculate the network behavior graph feature parameters of the current query result subgraph.

[0114] 3) Network relationship graph visualization area: located in the center of the page, the association relationship and propagation relationship between all network entities are displayed in the form of a relationship graph.

[0115] 4) Result record area: record the result log and query calculation efficiency of each query.

[0116] 5) Network behavior statistics area: use various icon modules of Echarts and D3.JS to display various statistical data obtained from Elasticsearch and the graph database.

[0117] Experimental test:

[0118] The application carries out visual function test, graph feature parameter application case test, query efficiency test and data analysis test based on graph association query on the system. Specifically as follows:

[0119] (1) Network behavior association subgraph query function test

[0120] The application carries out network behavior query function test by querying an instance of a VPN operation log subgraph. It is known that a user with an account of gryffindor has logged in VPN, and the VPN access data related to the login data is queried. This case queries by inputting the corresponding data in the basic query area, and the query result is as shown in Figure 6 . Figure 6 The right side shows the search results under the query conditions in the red frame on the left side of the page. As can be seen from the figure, gryffindor accesses the VPN server of "Y.10.18.88", and the virtual session IP data generated is "X.10.18.134". Based on this virtual IP, gryffindor accesses the resource server "Y.10.18.145" and downloads files to the local through the FTP protocol, and the attribute details of the edge are viewed through the tooltip by placing the mouse on the edge generating the FTP association; The gyffindor account also generates a record of deleting the account "aaad" on the VPN server. In addition, when the subgraph of the query result is too much (the threshold is currently set to 200), the main attributes of the nodes and edges in the graph will be hidden to prevent the graph display from being chaotic, as shown in Figure 7 .

[0121] (2) Network behavior graph feature analysis application case test

[0122] The advanced settings area of the system of the application is mainly to let the user select the graph feature calculation parameters, as shown in Figure 8 . When the parameters are selected and "calculate" is clicked, the system will calculate the corresponding feature parameters on the current query subgraph. According to the graph feature calculation means proposed by the application, the feature analysis of the data stream behavior in the network is carried out. The network behavior stream records the interaction rules of the running service, and different network behaviors correspond to different network application protocols. In order to analyze the connection behavior of specific protocols and network streams, the application extracts the well-known port numbers and application layer protocols used in the network running process, and filters out the network stream connection relationship graphs of different network application stream connection behaviors, as shown in Figure 9 . The protocols are (a) SMTP graph, (b) DNS graph, (c) FTP graph, (d) Telnet graph and (e) HTTP graph in turn. And on each extracted subgraph, 6 kinds of graph feature parameters are calculated respectively, and the results are as shown in Table 1.

[0123] (3) Network graph storage platform performance test

[0124] 1) Network behavior data relationship and feature extraction performance test

[0125] Table 1 Different application flow behavior network flow connection relationship graph feature parameters

[0126]

[0127] In order to verify the effectiveness of the system proposed in the application in the network behavior query scene, the efficiency of the same query of the system of the application and the Elasticsearch database under the same configuration is compared.

[0128] The Elasticsearch of the application is deployed as follows: index is divided according to daily data, types are directly divided according to different data function sources under each index, and JSON data parsing values under the business are stored in the form of key-value in the filed of each type. Correspondingly, in the Janugraph database, the schema is constructed by using the four storage modes proposed in the application, and all data are sequentially warehoused.

[0129] The data is derived from the message queue channel pushed by a network security manufacturer every day, and in the two databases, data of three orders of magnitude are stored: the first order is 11.2G structured data pushed by the manufacturer within a day, with a total of 5,983,922 logs; the second order is 38.4G structured data pushed by the manufacturer within three days, with a total of 18,637,121 logs; and the third order is 82.1G structured data pushed by the manufacturer within seven days, with a total of 43,577,458 logs. The selection of network information query requirements: this section selects four basic association query scenes, represented by Q1 to Q4, which involve attribute query, statistical query, and different depth of association data query; and selects four types of graph calculation parameters set by the application as query scenes, represented by Q5 to Q8, because the query efficiency of these graph calculation parameters is closely related to the statistical speed of the network graph. The information query examples of statements Q1-Q8 and the query speed comparison of the two databases are shown in Tables 2 and 3.

[0130] Table 2 Q1 to Q8 query test statement examples

[0131]

[0132] Table 3 ES and JGDB query efficiency test results

[0133]

[0134]

[0135] From the comparison results in Table 3, it can be seen that in the Q1 attribute query and Q2 statistical query, the query speeds of the two databases are basically the same, and even ES is slightly faster than Janusgraph in statistical data query; and for the association relationship query Q3-Q4, it is shown that the deeper the query depth, the greater the difference in query efficiency between the two, for example, in the 7-day statistical data, when the 3-depth association relationship query is performed, the ES database takes more than ten seconds to query the corresponding result, and the JGDB query time is an order of magnitude smaller than that of the ES database.

[0136] In terms of graph computing parameters Q5-Q8, for the calculation of average degree, the difference in query calculation speed between the two is small, because in JGDB, two degrees are generated for each edge, and the calculation of average degree can be equivalent to the calculation of the number of connected edges e x 2 in the entire network, and then divided by the total number of nodes n. From the query comparison effect of Q2, it can be seen that the efficiency difference between ES and JGDB is not large in statistical query, so the average degree calculation speed difference is not large. In terms of node bias calculation, JGDB has a faster calculation speed than ES, which needs to be found from the underlying storage principle. When judging whether a node has out-degree and in-degree at the same time, JGDB can directly query the keyRow according to the ID key of each node, and the keyRow stores the edge information of the current node as out-degree and in-degree, so it can be directly judged whether the current node is a double-degree node. In the corresponding ES, the data is stored by session, and each piece of data contains source IP and destination IP. The source IP is only an out-degree node, and the destination IP is only an in-degree node. If you want to query whether one of the nodes is a double-degree node, you need to further connect the relevant data for judgment. In terms of maximum subgraph connectivity, ES and JGDB are both through breadth-first traversal to cover all nodes in the sub-network for statistical judgment. In terms of maximum depth calculation, both of them are through depth-first traversal to cover all nodes in the sub-network for statistical judgment. Although the calculation methods are the same, JGDB is faster in connecting nodes because it is faster in calculating connectivity and maximum depth.

[0137] 2) Efficiency comparison test before and after JGDB query strategy optimization

[0138] Following the above experimental device environment and three orders of magnitude of log data sets, this part optimizes the deployed graph database, modifies the Janusgraph-Server open source code, adds a query optimization model based on the SDDQN strategy, and adds a cache matching strategy and a cache replacement strategy in the Database-level cache related API.

[0139] This part will optimize the JGDB query engine before the optimization of the tuning strategy called DOPFA, and the optimized strategy is called SDDQN. Since the query execution strategy optimization in this section is mainly aimed at the optimization of the association relationship query, the original Q5-Q8 test set in the last section is removed, and more association relationship queries are added on the basis of the original 4 query statements: new Q5-Q8 is the basic relationship query statement, and the statement format is "g.V().has(*).both(*).has(*)", Q9-Q12 is a complex condition query statement, and the statement format is "g.V().match(_.as(*).has(*).both(*).as(*),_.as(*).both(*).has(*)…)". This section uses Q1 to Q14 query statements, respectively, in the DOPFA, SDDQN query environment, and the log data is divided into 1 day 5,983,922, 4 days 18,637,121, and 7 days 43,577,458 orders of magnitude to perform query testing and comparison, and the comparison results are shown in Figs. 1 to 3. Figure 10

[0140] From the three efficiency comparison charts, it can be seen that the query efficiency under the SDDQN strategy is better than that under the DOPFA strategy in most cases, and as the database data increases, the difference between the query efficiency before and after optimization becomes more and more obvious. But there are some exceptions, the first case is Q1-Q3 category, which are attribute query, statistical query and fixed point query with depth of 1 degree, in this query case, operator optimization will not affect the algorithm at all, and even calling the model will slow down a little, and in the future, SDDQN optimization strategy should be applied only when the query association relationship is applied; the second case is that the operator optimization calls out the execution order slower than the original execution order, but this is an occasional case, which shows that the model still has further optimization space; finally, there are some cases where the query efficiency does not change before and after optimization, which mostly occurs in 1 degree query, which only involves two nodes, indicating that in the association relationship query with short statement chain, the optimization effect of the optimization model is not obvious.

[0141] The above-described embodiments only express the implementation of the present application, and the description is more specific, but it cannot be understood as a limitation on the scope of the patent of the present application. It should be noted that for ordinary skilled persons in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of protection of the present application. Therefore, the protection scope of the patent of the present application should be subject to the appended claims.​< / list> < / list> ​

Claims

1. A graph storage method for network behavior data, characterized by, Comprise the following steps: 1) data collection: collect traffic and log data from security vendors, complete preliminary integration and structured analysis of data via security vendors, and send to message queue; 2) data dump: obtain data from the message queue and perform data preprocessing, persistently store the preprocessed data and establish an index; 3) graph database storage: store the data stored in step 2) according to four types of single machine behavior, network flow, network basic application, and network security application, formulate four types of graph pattern storage structures, and store in JanusGraph distributed graph database; 4) backend data processing: for the JanusGraph distributed graph database, first embed the SDDQN-based graph database query execution strategy and the ID replacement-based query cache matching strategy, wherein the SDDQN-based graph database query execution strategy refers to constructing a DDQN query chain optimization algorithm SDDQN for a query operator Step chain based on a JanusGraph-Server retrieval engine, and using the SDDQN as a query execution strategy; the ID replacement-based query cache matching strategy refers to constructing a query cache matching storage strategy IDRC using ID instead of nodes and edges in the adjacency list based on the unique ID markers of nodes, edges, and properties in the adjacency list physical storage of the database level cache of the JanusGraph distributed graph database; then replace low-frequency caches through the cache replacement strategy to optimize the cache; finally, for the four types of graph pattern storage structures, encapsulate the standardized statement query interfaces of basic queries, complex queries, and graph computing queries, and extract graph computing parameters for network behavior description and encapsulate as network graph invocation interfaces; 5) user service: create a dynamic interactive visualization interface for users, call the query interface and network graph invocation interface, and provide network behavior data association query and network behavior feature query for users.

2. The method of claim 1, wherein, The data preprocessing in step 2) includes three steps of field normalization, repeated log removal, and meaningless data removal.

3. The method of claim 1, wherein, The method for persistently storing and establishing an index for the preprocessed data in step 2) is to use Hadoop HDFS as a distributed storage persistent layer, use Hbase as a data management layer, embed Elasticsearch as an index tool to provide full-text indexing function for the upper JanusGraph, and use Zookeeper cluster to guarantee data consistency scheduling.

4. The method of claim 1, wherein, In step 4), SDDQN intercepts the analysis operator Step chain of JanusGraph-Server retrieval engine, uses query time as feedback, approximates the action value function under the state of multiple combinations of data attributes and operators, learns the best combination strategy between Steps in the long execution operator Step chain, reduces the size of intermediate node hits in association query, and improves query speed.

5. The method of claim 1, wherein, In step 4), SDDQN includes the following four algorithm modules: The operator Step chain cutting module is used for marking the division for the sub-operator Step chain containing the execution scope, reminding that the operator state transition cannot cross the mark when transitioning; The operator feature extraction module is used for normalizing each operator into a five-tuple composed of the serial number of the current operator, the operator function name, the parameter name, the parameter value and the limited range; The DDQN decision maker module is used for DDQN training and decision making, by constructing an experience replay pool and storing the current and historical samples of the interaction between the operator Step chain and the JanusGraph-Server; by random sampling training from the experience pool, the action value selection and the behavior evaluation are trained by using two neural network structures of the DDQN respectively; and the convergence speed is improved by using the ε-greedy algorithm; The operator logic restoration and verification module is used for performing action verification after each step of Action selection in the DDQN, performing Step chain verification of the operator based on the Standard Verification Strategy of the JanusGraph-Server after all decision executions are completed, adding finalEndStep at the tail of the operator Step chain and locking the operator Step chain after the verification, and finally performing filtering operation and database query for different operators.

6. The method of claim 5, wherein, The specific functions of the DDQN decision maker module are as follows: Before training the DDQN, an initial state is set, which contains an empty list L new and a list L of all operators in the query statement steps ; When each time an action a t is performed, an operator is selected from L steps and added to the list L new , the list L new of selected operators forms a state s t , all states form a state set S, when L new , L steps are of the same length, s t reaches the end state. When each state transition, the next selected operator's action as an action a t and according to the state-action value function, i.e. the ε-greedy algorithm, select the action a that should be performed t ; Performing action verification on the selected operator, when the selected operator is one of the positioning operator SelectStep, the matching operator MatchStep, the output operator MapStep and the operator carrying conditions in chain division, judging whether the variables contained in the current state have been placed in the five-tuple of the existing operator in the chain, if not, the behavior is invalid, and a new behavior is selected by re-executing the state-action value function; When the selected operator is one of the HasStep / WhereStep condition restriction operator and the AsStep initialization operator, it is judged whether the operator is adjacent to the node operator, if not adjacent, it is invalid.

7. The method of claim 6, wherein, selecting an action a to perform according to the state-action value function t comprises: Each time an action selection action a is performed t , the state-action value function anticipates whether the current state s t has used all the operators, and if there are operators that have not been used, and a t is the action that has the highest value, then the feedback value r t = 0 is set and the current selected action is taken to the next state; If the operator is not used, and a t If the action is not verified, set r t = -1, next time in the current state s t No longer select the operator, and directly enter the termination state; If all operators are already in the current state s t Once all operators have been selected and the operator Step chain validity check passes, the complete operator Step chain query is executed directly in the environment. Let r t =λexp(-τ), where λ is a hyperparameter used to adjust the influence of the feedback value, and τ is the length of the database query time; If all the operators are used and the validity check of the operator Step chain is passed, when the time τ exceeds the upper limit of the query time τ0 in the execution of the operator Step chain query, let r t = -1.

8. The method of claim 1, wherein, The cache matching rule executed by the query cache matching strategy based on ID replacement in step 4) is as follows: (1) Set temporary variable result <list>is used for storing the data obtained by the query;< / list> (2) obtaining the queries array composed of all key values in the query cache set, taking out each query statement query-key in a loop, and judging whether there is a string matching the current user query statement query in full bytes, if there is, terminating the loop, recording the current query-key value and performing step (3); if the last value is not matched successfully, directly performing step (6); (3) taking out the corresponding ValueObject object according to the matched query-key object, simultaneously performing an increment operation on the use time attribute of the object; setting lastUseDate equal to the current time; and obtaining the Boolean value of isSubGraph, if true, performing step (4), otherwise performing step (5); (4) return the list of subgraph IDs according to the ValueObject object, traverse the list to restore the node, edge and attribute corresponding values, generate the list of subgraphs, assign the list to the result variable, and execute step (7) (5) return the subgraph shortValue value according to the ValueObject object, and assign the value to the result, and then execute step (7); (6) if the matching fails, enter the normal database query operation, update the memory cache, assign the query result to the result, and enter step (7); (7) return the result list, complete all steps and jump out.

9. The method of claim 1, wherein, In step 4), The cache replacement strategy is as follows: First, 30% of the space in the cache is used to store low-frequency recurring statements, and the remaining space is used to store hot statements; Then, when a statement is queried, it is first stored in the hot statement area; and records with less than 2 times of usage within 1 day in the hot statement area are regarded as occasional records without the need for caching, and are directly removed from the cache; Finally, statements with less than 10 times of usage within 1 week are regarded as low-frequency recurring statements, and are placed in the low-frequency recurring statement area; when the cache is too large or the memory is about to overflow, the cache in the low-frequency recurring area is directly cleared, and old statements are replaced in the hot cache area according to the LFU strategy to achieve optimal cache; and / or The basic query includes attribute query, statistical query, grouping query, node query, relationship query and depth matching query; And / or The complex query includes long path query and traversal query; and / or The graph computing parameters include network behavior graph average degree, network behavior graph node bias, subgraph number, maximum subgraph connectivity rate and maximum depth of one-way connection.

10. A graph storage system for network behavior data, comprising a memory and a processor, a computer program is stored on the memory, and the processor implements the steps of the method of any one of claims 1-9 when executing the program.

Images