JP2006268775A - Software operation modeling device and software operation monitoring device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a software operation modeling device, capable of performing right and wrong determination upon detection of an unlearnt operation while preventing false attack. <P>SOLUTION: The software operation modeling device 100 comprises an instruction acquisition part 110 acquiring instructions issued by monitoring object software 10 during operation; an instruction accumulation part 120 accumulating the acquired instructions in time series for every trial; a model generation part 130 reading the time series of instructions accumulated in the instruction accumulation part 120 for every trial, and generating an operation model from the time series of instructions; and a model accumulation part accumulating operation models of the monitoring object software generated by the model generation part 130 by the previous reading. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a software behavior modeling device and a software behavior monitoring device.

  All computers such as PCs, workstations, servers, routers, mobile phones, and PDAs are exposed to attacks from outside or inside. A typical attack is based on the vulnerability of software running on a computer. An attacker sends malicious execution code that uses software vulnerabilities to the computer, takes control of the running process, and performs unauthorized operations using the authority of the process. As countermeasures against attacks using software vulnerabilities, systems that detect abnormalities in running software have been disclosed (for example, see Non-Patent Document 1 and Non-Patent Document 2).

  The system described in Non-Patent Document 1 acquires the software source code in advance and statically analyzes the source code to obtain a normal operation of the software, that is, a system call issue pattern issued during normal operation. By creating a model to represent and checking whether the execution sequence of the software is accepted by this model, a deviation from normal operation, that is, abnormal operation is detected. The model is generated by a compiler, and the feature of this system is that the model is described by a deterministic finite automaton. The software source code has many places that cause non-determinism such as conditional branches and function calls, so static analysis can only generate models with non-deterministic automaton classes, but the automaton generated for each function Non-determinism is reduced by adding and modifying serial connections and original system calls. In addition, function pointers, longjmp instructions, and signals cannot be reflected in the automaton by static analysis due to their properties, but they can be handled by dynamically reflecting them in the model while operating the monitored software. It is also a feature.

  The system described in Non-Patent Document 2 also creates a model that represents the normal operation of software, that is, the system call issue pattern, as in Non-Patent Document 1, but does not use source code and is isolated from attacks. The software is operated by, the input / output logs obtained there are acquired, and the model is learned. A feature is that a nondeterministic finite automaton having a system call, call stack status, and a program counter as an input sequence and a program counter as a status, a system call, and a call stack status as an edge is generated by learning. The system call program counter may change during learning and verification (eg, when using a dynamic link library), but verification can be performed by using the system call program counter as the address of the most recent static link function. At times, the learned automaton can be used.

Whether the instruction set issued in normal operation is set in advance, and whether the instruction acquired during computer operation is included in the instruction set issued in normal operation set in advance A computer operating state monitoring device for verifying the above is also disclosed (for example, see Patent Document 1). In this case, when an instruction that should not be issued in normal operation is issued, it is determined that there is an abnormality.
JP 11-219304 A L. Lam et al. “Automatic Extraction of Accurate Application-Specific Sandboxing Policy”, EUROCOM International Symposium on Recent Advances in Intrusion Detection (RAID) 2004, September 2004 D. Gao et al. “On Gray-Box Program Tracking for Anomaly Detection”, 13th USENIX Security Symposium, August 2004

  In the system described in Non-Patent Document 1, it is necessary to obtain the source code of the software in advance, but it is easy for the software provider not to disclose the source code in order to prevent unauthorized use of the software. The software provider can analyze the source code statically and send the generated model to the terminal side, but the model has almost the same meaning as the source code, so it is almost the same as the source code disclosed. . As a result, software providers may not even disclose models. In addition, this system considers verification of the place where execution code control changes, such as conditional branching and function pointers, but does not verify whether conditional branching operates in accordance with source code.

  In the system described in Non-Patent Document 2, a value that is not a system call program counter is used as a system call program counter. Therefore, the attacker can disguise the value of the program counter and generate an attack code accepted by the model. In order for an attacker to perform this camouflage, it is necessary to know the value of the program counter accepted by the model. Therefore, it is conceivable to randomize the program counter and conceal the value of the program counter in order to protect it from impersonation. However, in order to conceal it completely, source code is required. As described above, it is difficult to apply for the same reason as the system described in Non-Patent Document 1. The model is described by an automaton with the program counter as a state. Automata is an efficient model when past verification results are not used for the current verification, but because the program counter is in a state, there are multiple states of incoming lines due to conditional branching, etc. When trying to verify correctly, it is inefficient because it is necessary to retain the results of past conditional branches.

  Further, both the systems described in Non-Patent Document 1 and Non-Patent Document 2 model the generation pattern of system calls, but issuing system calls only models a part of the operation of software. As a result, attackers could use buffer overflows, etc. to disguise program counters and return addresses to be accepted by the model, issue system calls, and execute malicious execution code ( Camouflaged attack).

  The computer operating state monitoring device described in Patent Document 1 performs monitoring using instructions that are more detailed data than system calls, but does not consider the time series of instructions, so during normal operation It is easy to write attack code using only issued instructions. Therefore, it cannot be said that an attack can be detected reliably.

  In addition, the techniques described in Non-Patent Document 2 and Patent Document 1 that learn a model from system calls and instructions issued from actual software operations must try all the operations of the monitored software at the learning stage. However, it is generally impossible to try including data stored in the data area, or to try a combination of all operations. For this reason, at the time of verifying the operation of the software, it is originally a normal operation of the software but has not yet been learned, so it must be determined that the operation is not normal (false detection).

  Therefore, in view of the above-described problems, the present invention provides a software behavior modeling device and a software behavior monitoring device that can prevent an impersonation attack and can make a right / bad judgment when an unlearned motion is detected. Objective.

  In order to achieve the above object, a first feature of the present invention is a software operation modeling device for modeling normal operation of monitoring target software, wherein the monitoring target software is tried a plurality of times, and (a) monitoring target An instruction acquisition unit for acquiring instructions issued during operation of the software; (b) an instruction storage unit for storing the acquired instructions in time series for each trial; and (c) a time series of instructions stored in the instruction storage unit. For each trial, and a model generation unit for creating an operation model from the time series of instructions, and (d) a model storage unit for storing the operation model of the monitored software generated by the model generation unit until the previous reading. The model storage unit (e) the model generation unit A first model storage unit that stores the tree structure model generated up to now, and (f) a second model in which the model generation unit stores an operation model whose feature value is an instruction issuance statistic generated up to the previous reading. The model generation unit includes (g) a time series of instructions read this time as a learning sequence, and a tree structure model is obtained from the learning sequence and the motion model stored in the first model storage unit. A first model generation unit for generating, and (h) a second model generation for deriving a statistic from the learning sequence and further learning an operation model stored in the second model storage unit using the statistic And a software operation modeling device having a section.

  According to the software behavior modeling apparatus according to the first feature, it is possible to perform monitoring using a time series of instructions, which is more detailed data than a system call, and to generate a model that can make an impersonation attack almost impossible. In addition, since each point of the tree structure model does not include information such as a program counter that sets a plurality of entering lines, the model holds the results of past conditional branches. That is, it is possible to generate a model that can correctly verify the conditional branch.

  In addition, an unlearned operation must be determined as an abnormal operation only with a tree structure model, but an operation model characterized by statistics issued by instructions can be generated simultaneously with the generation of the tree structure model.

  In the software behavior modeling device according to the first feature, the second model accumulation unit accumulates an operation model having the feature co-occurrence frequency of instructions generated by the model generation unit up to the previous reading, The second model generation unit may derive a statistic from the learning sequence, and further learn the behavior model stored in the second model storage unit using the co-occurrence frequency.

  In order to attack with software vulnerabilities, it is necessary to inject attack code that creates vulnerabilities, but this attack code is likely not present in the monitored program in the first place, and is statistically normal. Deviation from behavior can be considered. On the other hand, in the case of a behavior that is normally normal but not learned, the routine or function that existed in the monitored program is called as long as the behavior is normal. It can be said that it is highly possible.

  According to this software behavior modeling apparatus, it is possible to grasp the co-occurrence frequency of instructions in a normal state, and to generate a model that can capture changes in software behavior. When verifying the operation, if the unlearned operation was detected in the verification using the automaton or the tree structure model, it had to be determined to be abnormal. Is possible.

  Further, in the software behavior modeling device according to the first feature, when an abnormal operation of the monitored software is input, a negative example separation unit that separates a time series of instructions caused by the abnormal operation from the acquired instructions The negative example separation unit traces the acquired instruction on the behavior model accumulated in the first model accumulation unit, and the instruction time series from the point in time when the instruction different from the behavior model appears is caused by abnormal operation. The second model generation unit may determine a negative example that is an instruction sequence, and generate a model of an abnormal operation using the negative example.

  When discriminant analysis is performed using a statistical model, it is possible to perform accurate discrimination by learning a negative example. However, in order to input a negative example, it is necessary to extract the instruction caused by the abnormal operation from the operation of the software in the abnormal state.

  According to this software behavior modeling device, a difference from a positive example can be taken, and a negative example can be extracted.

  The software behavior modeling apparatus according to the first feature may further include a meta information adding unit that adds, as meta information, computer environment information in which the monitoring target software is operated to the generated operation model.

  Instructions vary depending on the computer environment. Therefore, when verifying the operation of the software, it is necessary to select a model having the same computer environment or to change the instruction on the model to the environment at the time of verification.

  According to this software behavior modeling apparatus, computer environment information can be given to the behavior model, and model selection and instruction change at the time of verification can be performed.

  A second feature of the present invention is a software operation monitoring apparatus that monitors the operation of monitored software, (a) an instruction acquisition unit that acquires instructions issued during operation of the monitored software, and (b) acquisition Each time the instruction acquisition unit acquires an instruction, the instruction acquisition unit acquires the tree structure model from the instruction storage unit that stores the instruction in time series, and (c) the first model storage unit that stores the tree structure model of the monitored software. A first verification unit that determines a deviation from a normal operation by tracing on the tree structure model; and (d) a first verification unit that is out of the time series of instructions accumulated by the instruction accumulation unit. The time series from the point of judgment is used as the verification series, and the monitored software installation The behavior model is obtained from the second model accumulation unit that accumulates the behavior model with the statistics issued as a feature, and the statistics from the verification sequence are generated. The gist of the present invention is that it is a software operation monitoring device including a second verification unit that determines a deviation.

  According to the software operation monitoring apparatus according to the second feature, a tree structure model that can reliably determine a normal state by monitoring instructions one by one, and an unlearned operation and an abnormal operation by monitoring the time series of instructions And a statistical model that can discriminate. While monitoring using a tree structure model, it is not necessary to generate and acquire a statistical model, which is efficient. Also, it is possible to judge whether the unlearned operation is good or bad.

  Further, in the software operation monitoring apparatus according to the second feature, the second model storage unit stores an operation model having the feature amount as a co-occurrence frequency of instructions issued by the monitoring target software, and a second model verification unit May derive the co-occurrence frequency of instructions from the verification sequence and determine the deviation from the normal operation by discriminant analysis with the operation model.

  According to this software operation monitoring device, when verifying the operation, if it was detected by an automaton or a tree structure model that an unlearned operation was detected, it was determined that the operation was abnormal. Judgment can be made.

  Further, in the software operation monitoring apparatus according to the second feature, the time series of the instructions accumulated by the instruction accumulation unit is used as a learning sequence, the tree structure model accumulated in the first model accumulation unit, and the second model accumulation unit A model learning unit that learns, using a learning sequence, an operation model that uses the issuance statistic accumulated in the instruction as a feature amount, and the model learning unit includes a second verification unit, The model may be learned only when it is determined that the operation is normal.

  The behavior model using statistics is not used as much as possible because the cost of calculating the statistics from the time series of instructions is generated.

  According to this software operation monitoring device, the unlearned operation can be reflected in the tree structure model, so that the next monitoring can be performed efficiently.

  In the software operation monitoring apparatus according to the second feature, the verification sequence may be a set of time-series subsequences of instructions issued until the monitored software ends. This partial sequence may be generated by dividing the time series of instructions by the timing at which the monitoring target software issues a system call.

  Statistics are calculated by the second verification unit, but it is possible to detect anomalies more quickly by targeting subsequences than by calculating the sequence of instructions up to the end. When the attack code is included in the sequence, the rate at which the attack code is closed in the sequence for calculating the statistic is increased, and it is easier to determine the deviation from the normal operation. The trigger that determines the end of the sub-sequence is issued by a predetermined number of instructions, a system call is issued, jmp, call, ret, etc. Instructions are issued, etc. In particular, when a system call is used, it is a good timing to inspect through which instruction issuance the system call is issued. An attacker must issue a system call in order to affect the system with a program vulnerability, but it detects attack code that creates a vulnerability by dividing the subsequence at the issue timing of the system call. The possibility of being able to be increased.

  According to the present invention, it is possible to provide a software behavior modeling device and a software behavior monitoring device that can prevent a spoofing attack and can make a good / bad judgment when an unlearned motion is detected.

  Next, embodiments of the present invention will be described with reference to the drawings. In the following description of the drawings, the same or similar parts are denoted by the same or similar reference numerals. However, it should be noted that the drawings are schematic.

<First Embodiment>
As shown in FIG. 1, the software behavior modeling apparatus 100 according to the first embodiment causes the monitoring target software 10 to try a plurality of times, and generates an operation model representing the operation of the monitoring target software. Further, as shown in FIG. 2, the software operation monitoring apparatus 200 according to the first embodiment monitors the operation of the monitoring target software 10 using the operation model generated by the software operation modeling apparatus 100, and detects an abnormality. Verify that there is no operation.

(Software behavior modeling device)
As shown in FIG. 1, the software behavior modeling device 100 includes an instruction acquisition unit 110 that acquires instructions issued during operation of the monitoring target software 10, an instruction storage unit 120 that stores a time series of the acquired instructions, An instruction time series stored in the instruction storage unit 120 is regarded as a learning series, a model generation unit 130 that generates an operation model, and a first model storage unit 140 that stores a tree structure model generated by the model generation unit 130; And a second model storage unit 150 that stores the co-occurrence frequency model generated by the model generation unit 130. The model generation unit 130 includes a first model generation unit 131 that generates a tree structure model from the instruction time series stored in the instruction storage unit 120, and a second model generation unit 132 that generates a co-occurrence frequency model. .

  The instruction acquisition unit 110 acquires an instruction each time the monitored software issues an instruction by using Linux PTRACE.

  The instruction storage unit 120 stores the acquired instructions in time series for each trial.

  The first model generation unit 131 compares the behavior model with the learning sequence in time series, and when an instruction different from the behavior model appears on the learning sequence, the first model generation unit 131 adds a new side to the behavior model to generate a tree structure. Generate a model.

  The first model storage unit 140 stores the tree structure model generated by the first model generation unit 131 until the previous reading.

  The second model generation unit 132 derives a statistic such as the co-occurrence frequency from the learning sequence, and further learns the behavior model accumulated in the second model accumulation unit using the statistic.

  The second model accumulating unit 150 accumulates an operation model having a statistic such as a co-occurrence frequency of instruction issuance generated by the second model generating unit 132 until the previous reading as a feature amount.

  The meta information adding unit 170 adds the computer environment information on which the monitoring target software 10 is operated as meta information to the generated operation model.

  FIG. 3 shows an example of the data structure of the behavior model. The data structure of the behavior model is composed of an instruction table 30 and a branch destination address table 40. The instruction table 30 includes an instruction name string 31 that records an instruction identifier and a branch pointer string 32 that records a pointer to a branch destination address table, and represents an instruction time series, that is, a tree-structured edge. The branch destination address table 40 is an array of a branch destination address column 41 that stores the address of the instruction table, and links the instruction before branching with the branch destination side.

(Software behavior modeling method)
Next, the software behavior modeling method according to the first embodiment will be described with reference to FIGS. FIG. 4 is an example of a flowchart in which the first model generation unit 131 generates a tree structure model from the instruction time series stored in the instruction storage unit 120. The tree structure modeling includes a modeling function, a generation function that is called by the modeling function and generates an initial model, and a learning function that is called by the modeling function and learns the tree structure model stored in the first model storage unit 140. Is used.

  First, in step S <b> 101, the modeling function acquires an operation model of the monitoring target software stored in the first model storage unit 140.

  Next, in step S102, it is determined whether or not the model acquisition is successful. If successful, the process proceeds to step S103, and the learning function is called. If unsuccessful, the process proceeds to step S104 and the generation function is called. The learning process in step S103 and the generation process in step S104 will be described in detail later.

  Next, in step S <b> 105, the generated or learned behavior model is accumulated in the first model accumulation unit 140. At this time, the environment information (for example, processor information of Intel x86 processor etc., the instruction name will change if the processor changes) at the time of acquiring the instruction is given to the model. A suitable model can be selected. Acquisition of environmental information and addition of meta information are performed by the meta information adding unit 170. The environment information is acquired by looking at the location where the environment information is stored, for example, in Linux, / proc / cpuinfo contains CPU information, but looks at / proc / cpuinfo. The acquired information is given to the model as meta information.

  Next, details of step S104 in FIG. 4 will be described with reference to FIG.

  In step S <b> 201, the generation function acquires the instruction time series of the monitoring target software from the instruction accumulation unit 120.

  Next, in step S202, it is determined whether the acquisition has succeeded. If the acquisition has failed, the process proceeds to step S203 to perform error processing, and the function ends. On the other hand, if successful, the process proceeds to step S204, and the instructions are read sequentially from the beginning of the time series.

  Next, in step S205, when the instruction reading is finished, the generation function is finished.

  On the other hand, if the instruction reading has not been completed in step S205, an instruction table is created in step S206, and in step S207, the instruction name is stored in the instruction name string and null is stored in the branch pointer string. Then, the process returns to step S204 to acquire the next instruction.

  Next, details of step S103 in FIG. 4 will be described with reference to FIG.

  First, in step S <b> 301, the learning function acquires an instruction time series of the monitoring target software from the instruction storage unit 120.

  In step S302, it is determined whether or not the acquisition has succeeded. If the acquisition has failed, the process proceeds to step S303, error processing is performed, and the function is terminated. On the other hand, if successful, the process proceeds to step S304, and the instructions are read sequentially from the beginning of the time series.

  Next, it is determined whether or not the instruction reading has been completed. If it has been completed, the generation function is terminated. If not completed, the process proceeds to step S306 to trace the tree. The tree trace will be described in detail later.

  Next, in step S307, if it is determined that “the read instruction exists” as a result of tracing, the next instruction is acquired. If it is determined that “new”, the process proceeds to step S308. In step S308, an instruction table is generated. In step S309, a branch destination address table is generated, and the address of the newly generated instruction table is stored in the branch destination address string. In step S310, the instruction name is stored in the instruction name string and the address of the branch destination address table is stored in the branch pointer string, and the process returns to step S304 to acquire the next instruction.

  Next, details of step S306 in FIG. 6 will be described with reference to FIG.

  First, in step S401, the contents of the instruction table are confirmed using the current position indicating the currently traced address.

  Next, in step S402, it is confirmed whether or not the acquired instruction is registered in the instruction name. If the instruction is registered (if the instruction is not new), the process proceeds to step S410 to determine that it exists. In step S405, the current position is updated to the next address, and the tree trace is terminated.

  On the other hand, if it is not registered in step S402, the value of the branch pointer is confirmed. If it is null, the process proceeds to step S404, where it is determined that the instruction is a new instruction, and in step S405, the current position is updated to the next address. Ends the tree trace.

  If it is not null in step S403, a branch destination address table is looked up using the value of the branch pointer in step S406, and branch destination addresses are obtained in order.

  Next, in step S407, it is determined whether or not the acquisition is successful. If the acquisition is successful, the process proceeds to step S408, and the instruction name at the head of the instruction table to which the branch destination address is drawn is confirmed. In step S409, it is confirmed whether or not the acquired instruction is registered. If it is registered (if the instruction is not new), the process proceeds to step S410, and it is determined that it exists. In step S405, the current position is updated to the next address, and the tree trace is terminated. On the other hand, if it is not registered in step S409, the process returns to step S406 to acquire the next branch destination address.

On the other hand, if the acquisition fails in step S407, it is determined that the instruction is a new instruction in step S404. In step S405, the current position is updated to the next address, and the tree trace is terminated.

  Next, how the model is learned will be described with reference to FIGS.

  FIG. 8 is an instruction time series stored in the instruction storage unit 120. A serial number is assigned to the leftmost column, which is read sequentially from 1 and converted into a model.

  FIG. 9 shows a model at the time when learning is completed after reading the second instruction time series. In the 6th instruction in the time series, jmp in the 1st time series and pop in the 2nd time series exist, so the address (AAAAAAAA) to the branch destination address table is registered in the jmp branch pointer column. The second instruction table is learned by the branch destination address table.

  FIG. 10 is a model at the time when learning is completed after reading the third instruction time series. The instruction time series is sequentially read, but in the 19th instruction on the 3rd instruction time series, there is a new instruction mov that is not registered in the model of FIG. The address (BBBBBBBB) to the branch address table is registered, and it is learned that the third instruction table is drawn by the branch destination address table.

  Next, a software behavior modeling method according to the first embodiment will be described with reference to FIGS. The second model generation unit 132 generates an N-gram from the time series of instructions stored in the instruction storage unit 120, and generates the appearance probability of each N-gram as an operation model. The appearance probability calculated here is obtained by dividing the appearance frequency of each N-gram by the sum of the appearance frequencies of all the generated N-grams. This denominator is an instruction obtained from multiple trials. N-grams generated from the time series may be obtained in a comprehensive manner, or may be obtained for each trial.

  FIG. 11 is a flowchart illustrating an operation example of the second model generation unit 132. The second model generation unit 132 includes a modeling function, a generation function, and a learning function.

  First, in step S <b> 501, the modeling function acquires a model corresponding to the monitoring target software from the second model storage unit 150.

  If acquisition is successful in step S502, the process proceeds to step S503. If acquisition fails, the process proceeds to step S504. Details of step S503 and step S504 will be described later.

  Next, in step S <b> 505, the learned and generated model is stored in the second model storage unit 150. When accumulating, the environment information obtained when the instruction is acquired is given to the model, so that a suitable model can be selected when learning the model next time or at the time of verification.

  Next, details of step S504 in FIG. 11 will be described with reference to FIG.

  First, in step S601, in the generation function, an instruction time series is acquired from the instruction storage unit 120. If acquisition is successful in step S602, the process proceeds to step S304 to generate an N-gram. In step S305, the appearance frequency of each N-gram is calculated, and the generation ends.

  On the other hand, if acquisition fails in step S602, generation is terminated after error processing.

  The N-gram generated here is, for example, a sequence of consecutive N words with one instruction as one word. For example, “A New Method of N-gram Statistics for Large Number of n and Automatic Extraction of Words and Phrases from It is generated by using the algorithm described in “Large Text Data of Japanese”. In the present embodiment, one instruction is handled as one word, but a plurality of instructions may be handled as one word, and the function is not limited.

  Next, details of step S503 in FIG. 11 will be described with reference to FIG.

  First, in step S701, the learning function acquires an instruction time series from the instruction storage unit 110, and when acquisition is successful, in step S704, an N-gram is generated using the above method, and in step S705. , Update the frequency of appearance of each N-gram in the model and add new entries.

  On the other hand, if acquisition fails in step S702, generation is terminated after error processing.

  FIG. 14 shows an example of an N-gram. The number located on the right is the appearance frequency. In this embodiment, 3-gram is taken as an example, but the number of N is not limited.

  N-gram is a linguistic processing method that consists of a sequence of N characters or words in a stream, and is an excellent method that can understand the co-occurrence of characters and words with a lightweight algorithm. is there. The software is composed of source code and binary code on a library called from the source code. That is, in order to generate software having different operations, the source code is generally changed. Some software allows the execution code to be entered from the outside and can dynamically change the operation, but the instruction issued during the execution of the software changes as the operation changes. That is, in either case, if the operation changes, an instruction time series having a co-occurrence relationship different from the normal state is issued.

  In the case of a normal and unlearned operation, a sample that is statistically close to the model is likely to be obtained if the instruction is issued from the same source code. This is because the instructions are generated through a compiler under the same environment. Attack code created by attackers is often written in assembler (or machine language), and when attacked by software, there is a possibility of issuing an instruction time series having a co-occurrence relationship different from the instruction issued by the execution code. high.

(Software operation monitoring device)
As shown in FIG. 2, the software operation monitoring apparatus 200 has a first model storage unit 250 that receives the monitoring target software 10 and stores the tree structure model generated by the software operation modeling apparatus 100, and an instruction issuance instruction. It is connected to a second model accumulation unit 260 that accumulates an operation model characterized by a statistic (for example, the co-occurrence frequency of instructions).

  Also, the software operation monitoring apparatus 200 according to the first embodiment includes an instruction acquisition unit 210 that acquires instructions issued while the monitoring target software 10 is operating, and an instruction storage unit 220 that stores the acquired instructions in time series. Each time the instruction acquisition unit 210 acquires an instruction, the instruction verification unit 230 that verifies the instruction issued by the monitored software with the tree structure model acquired from the first model storage unit 250, and the instruction storage unit 220 Of the accumulated instruction time series, the instruction issued after the first verification unit 230 detects an abnormal operation is regarded as a verification series, and the instruction issuance statistics obtained from the second model storage unit 260 (example) For example, a second verification unit 240 that verifies instructions issued by the monitored software with an operation model characterized by the co-occurrence frequency of instructions). Operates only when an abnormality is detected in the operation.

  That is, the first verification unit 230 acquires the tree structure model from the first model storage unit 250 that stores the tree structure model of the monitoring target software, and each time the instruction acquisition unit 210 acquires the instruction, the tree structure model is acquired. The deviation from the normal operation is determined by tracing above.

  In addition, the second verification unit 240 uses the time series from the time point when the first verification unit 230 determines that there is a divergence among the time series of instructions stored by the instruction storage unit 220 as the verification series, and the instructions of the monitored software The behavior model is acquired from the second model accumulation unit 260 that accumulates the behavior model having the statistic such as the co-occurrence frequency of the issue as a feature amount, the statistic is generated from the verification sequence, and the discriminant analysis with the behavior model is performed. The deviation from the normal operation is determined.

  The model learning unit 270 uses the time series of the instructions accumulated by the instruction accumulation unit 220 as a learning sequence, the tree structure model accumulated in the first model accumulation unit 250, and the instructions accumulated in the second model accumulation unit 260. The learning model is learned using the learning sequence with the statistical amount of issue as a feature value. The model learning unit 270 learns the model only when the second verification unit 240 determines that the operation of the monitoring target software is normal.

  The verification sequence is a set of time series subsequences of instructions issued until the monitored software is terminated. This partial sequence is generated by dividing the time series of instructions by the timing at which the monitoring target software issues a system call.

  The first model storage unit 140 and the first model storage unit 250 may be the same. Further, the second model storage unit 150 and the second model storage unit 260 may be the same.

(Software operation monitoring method)
Next, a software operation monitoring method according to the first embodiment will be described with reference to FIGS. 15 and 16.

FIG. 15 is a flowchart illustrating an operation example of the first verification unit 230. First, in step S901, an operation model of the monitoring target software is acquired from the first model storage unit 250. At this time, it is preferable to acquire the operating environment of the monitoring target software, collate with the meta information given to the operating model, and acquire the model according to the operating environment.

  Next, in step S902, the instructions accumulated in the instruction accumulation unit 220 are sequentially acquired. Then, in step S903, it is determined whether or not the process has been completed. If the process has been completed, it is determined that the process is normal in step S904, the determination result is output in step S908, and the monitoring is terminated.

  On the other hand, if it is not completed in step S903, a tree trace (refer to FIG. 7 for details) is called in step S905.

  Next, in step S906, it is determined whether or not the determination result is new. If the determination result is new, it is determined in step S907 that the determination is abnormal. In step S908, the result is output and monitoring is terminated.

  On the other hand, if the determination result is not new in step S906, that is, if it is present, the process returns to step S902 to acquire the next instruction.

  Hereinafter, how the monitoring target software is monitored will be described with reference to FIGS.

  9 is stored in the first model storage unit 250, and the instruction time series No. 1 described in FIG. 8 is stored in the instruction storage unit 220. .

  Instructions are sequentially read from the beginning of the instruction time series, and the deviation from the model is determined. In this case, since all the instructions on the instruction time series exist on the model (the result of the tree trace is “existence”), the operation verification unit outputs a result indicating that it is normal.

  Next, it is assumed that the model illustrated in FIG. 9 described when generating the model is stored in the first model storage unit 250, and the instruction time series No. 3 illustrated in FIG. 8 is stored in the instruction storage unit 220. Suppose that Instructions are sequentially read from the beginning of the instruction time series, and the deviation from the model is determined. In this case, in the 19th instruction, a new instruction mov is detected, and the operation verification unit outputs a result indicating that it is abnormal.

  FIG. 16 is a flowchart illustrating an operation example of the second verification unit 240.

  First, in step S <b> 1001, the second verification unit 240 acquires an operation model of the monitoring target software from the second model accumulation unit 260. At this time, it is preferable to acquire the operating environment of the monitoring target software, collate with the meta information given to the operating model, and acquire the model according to the operating environment.

  Next, in step S1002, a verification sequence is acquired from the instruction time series stored in the instruction storage unit 220. The verification sequence is a sequence of instructions from the instruction at which abnormality determination occurs to the end, or a subsequence thereof. When the second verification unit 240 makes a statistical decision, a statistic is calculated. However, it is better to target a subsequence than to target a column of instructions until the end of the statistic calculation. If it is possible to detect anomalies early and an attack code is included in the sequence, the attack code close ratio increases in the sequence for calculating statistics, and the deviation from normal operation is judged more. It becomes easy. The trigger that determines the end of the sub-sequence is issued by a predetermined number of instructions, a system call is issued, jmp, call, ret, etc. Instructions are issued, etc. In particular, when a system call is used, it is a good timing to inspect through which instruction issuance the system call is issued. An attacker must issue a system call in order to affect the system with a program vulnerability, but it detects attack code that creates a vulnerability by dividing the subsequence at the issue timing of the system call. The possibility of being able to be increased. However, in this embodiment, the case of the sub-sequence will be described, but the function is not limited.

  Next, in step S1003, a time series of instructions is acquired, and it is determined whether the acquisition is completed. If the acquisition is completed, it is determined in step S1004 that the operation is normal. In step S1005, the determination result is output and monitoring is terminated.

  On the other hand, if the acquisition is not completed in step S1003, an N-gram is generated from the time series in step S1006. In step S1007, the appearance frequency of each N-gram is calculated, and the appearance probability is derived. .

  Next, in step S1008, the acquired behavior model and the appearance probability of the N-gram generated earlier are subjected to discriminant analysis. The discriminant analysis detects outliers by using linear discriminant analysis by appropriately setting a threshold value.

  In step S1009, it is determined whether or not it is normal as a result of the discriminant analysis. If it is normal, the process returns to step S1002 to acquire the next instruction time series.

  On the other hand, if it is determined in step S1009 that it is abnormal, it is determined in step S1010 that it is abnormal, in step S1011 it is output that it is abnormal, and monitoring is terminated.

(Action and effect)
According to the software model behavior modeling apparatus and the software modeling method according to the first embodiment, by performing tree structure modeling, monitoring is performed using a time series of instructions that are more detailed data than system calls. And can generate a model that can make a camouflaged attack almost impossible. In addition, since each state of the model does not include information such as a program counter that makes a plurality of incoming lines, the model holds the results of past conditional branches. That is, it is possible to generate a model that can correctly verify the conditional branch.

  In addition, by deriving statistics from the learning sequence and learning the behavior model stored in the second model storage unit 150 using the statistics, it is possible to grasp the co-occurrence relationship of instructions in the normal state. It is possible to generate a model that can capture changes in the operation of software. When verifying the operation, the automaton verification had to determine that it was abnormal if an unlearned operation was detected, but it can be determined statistically normal because it uses the co-occurrence relationship of instructions. is there.

  However, in this embodiment, N-gram is used as a method for measuring the co-occurrence frequency, but it is only necessary to be able to measure the co-occurrence frequency such as an association rule, and this is not particular.

  In addition, according to the software operation monitoring apparatus and the software operation monitoring method according to the first embodiment, it is possible to perform monitoring using the co-occurrence frequency of instructions, and to determine the normality / abnormality determination of unlearned operations stochastically. be able to.

  In addition, by arranging the second verification unit 240 after the first verification unit 230, the tree structure model that can reliably determine the normal state by monitoring the instructions one by one, and the time series of the instructions are displayed. By monitoring, an N-gram model that can discriminate between unlearned behavior and abnormal behavior can be used. While monitoring using the tree structure model, it is not necessary to calculate the appearance frequency of the N-gram, which is efficient.

  Further, the software operation monitoring apparatus 200 further includes a model learning unit 270, and is used in the second verification unit 240 when it is determined by the verification of the second verification unit 240 that the software operation is normal. A verification sequence may be added to the tree structure model. Since an operation model that uses a statistic such as an N-gram has a cost for calculating the statistic, it is better not to use it as much as possible considering the calculation cost. By adopting the above configuration, the unlearned operation can be reflected in the tree structure model, so that the next monitoring can be performed efficiently.

<Second Embodiment>
As a method for efficiently performing discriminant analysis, giving a negative example can be mentioned. In the first embodiment, only positive examples are handled. In the second embodiment, handling of both negative examples will be described.

(Software behavior modeling device)
As shown in FIG. 17, the software behavior modeling device according to the second exemplary embodiment includes a negative example separation unit 160 in addition to the software behavior modeling device shown in FIG. 1.

  The negative example separation unit 160 separates the time series of instructions generated by the abnormal operation from the acquired instructions when the abnormal operation (eg, attacked, bug-induced) of the monitoring target software is input. In addition, the negative example separation unit 160 traces the acquired instruction on the operation model stored in the first model storage unit 140, and the instruction time series from the point in time when the instruction different from the operation model appears by the abnormal operation. It is determined that this is a negative example that is the generated instruction sequence.

  The second model generation unit 132 generates a model of abnormal operation using a negative example.

  The instruction acquisition unit 110, the instruction storage unit 120, the first model generation unit 131, the first model storage unit 140, and the second model storage unit 150 are the same as those in the first embodiment. The description is omitted.

(Software behavior modeling method)
Next, a software behavior modeling method according to the second embodiment will be described with reference to FIG.

  First, in step S <b> 801, a model is acquired from the first model storage unit 140 and an instruction time series is acquired from the instruction storage unit 110.

  Next, in step S802, it is determined whether the acquisition is successful. If the acquisition is unsuccessful, the process proceeds to step S803, where error processing is performed and the process ends. On the other hand, if successful in step S802, instructions are sequentially read from the instruction time series in step S804.

  Next, in step S805, it is determined whether or not reading has been completed. If completed, error processing is performed in step S806, and the process ends. On the other hand, if the reading is not completed in step S805, the tree is traced (see FIG. 7 for details).

  Next, in step S808, it is determined whether or not the result of tree tracing is new. If it is new, in step S809, the time series from the current position to the end is subsequenced, this subsequence is extracted as a negative example, and the negative example separation ends. On the other hand, if it is not new in step S808, the process returns to step S804, and then an instruction is acquired.

(Action and effect)
According to the software behavior modeling apparatus and the software behavior modeling method according to the second embodiment, it is effective for discriminant analysis because pure data during abnormal operation can be modeled by separating negative examples. A discriminant space.

  Also, by using the tree structure model, the change point of the instruction issue pattern can be detected accurately, so that accurate negative examples can be extracted.

<Third Embodiment>
In the first and second embodiments, the software behavior modeling device and the software behavior monitoring device have been described as different devices, but these devices may be configured as one device.

(Software behavior modeling device)
The software behavior modeling apparatus 100 according to the third embodiment generates and accumulates an operation model of the monitoring target software 10, and performs operation monitoring based on the accumulated operation model.

  The software operation monitoring apparatus 200 includes an instruction acquisition unit 210 that acquires instructions issued while the monitoring target software 10 is operating, an instruction storage unit 220 that stores a time series of the acquired instructions, and instructions stored in the instruction storage unit. The time series is regarded as a learning series, and the model generation unit 130 that generates an operation model, the model storage unit 280 that stores the operation model generated by the model generation unit 130, and the operation model stored in the model storage unit 280 are used. And an operation monitoring unit 290 that determines a deviation from the normal operation of the monitored software.

  The instruction acquisition unit 210 acquires an instruction each time the monitoring target software 10 issues an instruction by using PTRACE of Linux or the like.

  The model generation unit 130 uses the instruction time series stored in the instruction storage unit 220 as a learning sequence, and generates a tree structure model based on the learning sequence. The model generation unit 130 includes an instruction based on the learning sequence. And a second model generation unit 132 for generating an operation model having the statistical quantity as a feature quantity.

  The first model generation unit 131 operates, for example, according to the flowchart shown in FIG. 4 and outputs the tree structure data shown in FIG. For example, the second model generation unit 132 operates according to the flowchart illustrated in FIG. 11 and outputs the N-gram illustrated in FIG.

  The model storage unit 280 includes a first model storage unit 250 that stores the tree structure model generated by the first model generation unit 131 and an instruction issuance statistic generated by the second model generation unit 132 (for example, co-occurrence). A second model storage unit 260 that stores an operation model having a frequency) as a feature amount.

  The operation monitoring unit 290 includes a first verification unit 230 that verifies an instruction issued by the monitoring target software with the tree structure model acquired from the first model storage unit 250 each time the instruction acquisition unit 210 acquires an instruction, and an instruction Of the instruction time series stored in the storage unit 220, the instruction issued after the first verification unit 230 detects an abnormal operation is regarded as the verification series, and the instruction issuance statistics obtained from the second model storage unit 260 are obtained. A second verification unit 240 that verifies the instruction issued by the monitored software 10 with an operation model characterized by (for example, the co-occurrence frequency of instructions), and the second verification unit 240 includes the first verification unit 230 detects abnormalities in software operation Only operates when was.

  The first verification unit 230 operates, for example, according to the flowchart shown in FIG. On the other hand, the second verification unit 240 operates, for example, according to the flowchart shown in FIG.

(Action and effect)
According to the software behavior model monitoring apparatus according to the third embodiment, it is possible to develop a terminal that models itself and verifies itself. Since modeling and verification can be performed in the same environment, there is no need to add meta information that conveys environmental information, which is efficient.

1 is a configuration block diagram of a software behavior modeling device according to a first embodiment. FIG. It is a block diagram of the configuration of the software operation monitoring apparatus according to the first embodiment. It is an example of the tree structure used in 1st Embodiment. It is a flowchart which shows the software operation modeling method which concerns on 1st Embodiment (the 1). It is a flowchart which shows the software operation modeling method which concerns on 1st Embodiment (the 2). It is a flowchart which shows the software operation modeling method which concerns on 1st Embodiment (the 3). It is a flowchart which shows the software operation modeling method which concerns on 1st Embodiment (the 4). FIG. 3 is an example of accumulated instruction time series in the first embodiment. FIG. In the first embodiment, it is an example of an operation model (part 1). In the first embodiment, it is an example of an operation model (part 2). It is a flowchart which shows the software operation modeling method which concerns on 1st Embodiment (the 5). It is a flowchart which shows the software operation modeling method which concerns on 1st Embodiment (the 6). It is a flowchart which shows the software operation modeling method which concerns on 1st Embodiment (the 7). In 1st Embodiment, it is an example of N-gram. It is a flowchart which shows the software operation | movement monitoring method which concerns on 1st Embodiment (the 1). It is a flowchart which shows the software operation | movement monitoring method which concerns on 1st Embodiment (the 2). It is a block diagram of the configuration of the software behavior modeling device according to the second embodiment. It is a flowchart which shows the software operation modeling method which concerns on 2nd Embodiment. It is a block diagram of the configuration of the software operation monitoring apparatus according to the third embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 ... Monitored software 30 ... Instruction table 31 ... Instruction name string 32 ... Branch pointer string 40 ... Branch destination address table 41 ... Branch destination address string 100 ... Software operation modeling device 110 ... Instruction acquisition part 110 ... Instruction storage part 120 ... Instruction accumulation unit 130 ... model generation unit 131 ... first model generation unit 132 ... second model generation unit 140 ... first model accumulation unit 150 ... second model accumulation unit 160 ... negative example separation unit 170 ... meta information Giving unit 200 ... Software operation monitoring device 210 ... Instruction acquisition unit 220 ... Instruction storage unit 230 ... First verification unit 240 ... Second verification unit 250 ... First model storage unit 260 ... Second model storage unit 270 ... MODE The learning section 280 ... model storage unit 290 ... operation monitoring unit

Claims (9)

A software behavior modeling device that models the normal operation of monitored software,
Let the monitored software try multiple times,
An instruction acquisition unit for acquiring instructions issued during operation of the monitored software;
An instruction storage unit for storing the acquired instructions in a time series for each trial;
A model generation unit that reads the time series of instructions stored in the instruction storage unit for each trial and creates an operation model from the time series of instructions;
A model storage unit that stores an operation model of the monitoring target software generated by the model generation unit until the previous reading;
The model storage unit
A first model storage unit that stores the tree structure model generated by the model generation unit up to the previous reading;
A second model accumulating unit for accumulating an operation model whose feature value is a statistical amount of instruction issuance generated until the previous reading by the model generating unit;
The model generation unit
A time series of instructions read this time as a learning series, a first model generation unit that generates a tree structure model from the learning series and the motion model stored in the first model storage unit;
A second model generation unit for deriving a statistic from the learning sequence and further learning the behavior model stored in the second model storage unit using the statistic; Behavior modeling device. The second model accumulating unit accumulates an operation model having the feature co-occurrence frequency of instructions generated by the model generating unit until the previous reading,
The second model generation unit derives a statistic from the learning sequence, and further learns the behavior model stored in the second model storage unit using the co-occurrence frequency. The software behavior modeling apparatus according to claim 1. When an abnormal operation of the monitoring target software is input, a negative example separation unit that separates a time series of instructions generated by the abnormal operation from the acquired instructions,
The negative example separation unit traces the acquired instruction on an operation model stored in the first model storage unit, and an instruction time series from the time when an instruction different from the operation model appears by an abnormal operation. Judged as a negative example of the resulting instruction sequence,
The software behavior modeling device according to claim 1, wherein the second model generation unit generates a model of an abnormal operation using the negative example.   The software operation according to any one of claims 1 to 3, further comprising a meta information adding unit that adds, as meta information, computer environment information in which the monitoring target software is operated to the generated operation model. Modeling device. A software operation monitoring device for monitoring the operation of monitored software,
An instruction acquisition unit for acquiring instructions issued during operation of the monitored software;
An instruction storage unit for storing the acquired instructions in time series;
By acquiring the tree structure model from the first model storage unit that stores the tree structure model of the monitoring target software, and tracing the tree structure model each time the instruction acquisition unit acquires the instruction, A first verification unit for determining a deviation from normal operation;
Among the time series of instructions accumulated by the instruction accumulation unit, the time series from the time point when the first verification unit determines to be a divergence is used as a verification series, and the statistical amount of instruction issuance of the monitored software is used as a feature quantity. The behavior model is acquired from the second model accumulation unit that has accumulated the behavior model, a statistic is generated from the verification sequence, and discriminant analysis with the behavior model is performed to determine a deviation from the normal behavior A software operation monitoring apparatus comprising: a verification unit. The second model accumulating unit accumulates an operation model having a feature amount of a co-occurrence frequency of instructions issued by the monitoring target software,
The said 2nd model verification part derives | leads-out the co-occurrence frequency of an instruction | indication from the said verification series, and discriminate | determines the deviation from a normal operation | movement by discriminant analysis with the said operation | movement model. Software operation monitoring device. A time series of instructions accumulated by the instruction accumulation unit is used as a learning sequence, and the tree structure model accumulated in the first model accumulation unit and the instruction issuance statistics accumulated in the second model accumulation unit are characterized. A model learning unit that learns the behavior model as a quantity using the learning sequence;
7. The software operation monitoring according to claim 5, wherein the model learning unit learns a model only when the second verification unit determines that the operation of the monitoring target software is normal. apparatus.   The software operation monitoring apparatus according to claim 5, wherein the verification sequence is a set of time series subsequences of instructions issued until the monitoring target software is terminated. . 9. The software operation monitoring apparatus according to claim 8, wherein the partial sequence is generated by dividing the time series of the instructions at a timing when the monitoring target software issues a system call.

Images