Behavior monitoring device, behavior monitoring method, and behavior monitoring program

Abstract

A behavior monitoring device (1) according to the present invention comprises: a filter unit (4) that acquires system-call calling information when calling a system call; a statistical data management unit (8) that records and manages the system-call calling information; a filter management unit (6) that controls activation / deactivation of the function of acquiring the system-call calling information by the filter unit; and a monitoring unit (7) that monitors the number of system calls on the basis of the system-call calling information of the statistical data management unit and detects an attack or an abnormality.

Description

Behavior monitoring device, behavior monitoring method, and behavior monitoring program

[0001] The present invention relates to a behavior monitoring device, a behavior monitoring method, and a behavior monitoring program for an information processing device.

[0002] In recent years, network virtualization, which utilizes server virtualization technologies such as hypervisors and containers to run network functions on general-purpose hardware, has progressed. Accordingly, network operators are procuring network functions as software images (hereinafter referred to as VNFs (Virtualized Network Functions, regardless of the virtualization format, such as virtual machines or containers)) and building a system to run them on general-purpose hardware, thereby realizing network virtualization.

[0003] However, if the procured VNF contains malicious software or vulnerabilities, there is a strong concern that attacks on general-purpose hardware, OS, and other operating images may be carried out via the VNF. Therefore, it is extremely important for the OS (hereinafter referred to as the host OS) that runs directly on the general-purpose hardware to monitor the behavior of the VNF and detect attacks and abnormalities.

[0004] It is known that utilizing statistical information on the issuance of system calls by the host OS is effective in detecting malicious behavior in VNFs and general applications, and there are also EDR (Endpoint Detection and Response) products that detect malicious behavior through monitoring.

[0005] For example, Patent Document 1 describes an anomaly detection device that, in order to detect abnormal behavior of an application that has been attacked or invaded by a malicious program, compares the normal call relationships between functions until a specific function to be monitored is called by the application program with the call relationships between functions until the specific function to be monitored is called by the application program in response to an event that calls the specific function to be monitored.If the comparison shows that the call relationships do not match, the device detects the function call operation associated with the event as abnormal behavior.

[0006] Also, Non-Patent Document 1 discloses a threat detection engine technology that uses plug-ins to extend threat detection to the entire cloud environment and detects threats at runtime by monitoring the behavior of applications and containers.

[0007] JP 2011-258019 A

[0008] “The Falco Project”, [online], Jan 30, 2024, The Falco Authors, [searched on February 1, 2020], Internet <URL: https: / / falco.org / docs / >

[0009] In the above prior art, in order to obtain statistical information on system calls, a function is inserted that performs information acquisition processing each time the target system call is called, etc. As a result, since network functions have very strict performance requirements such as latency, performing information acquisition processing each time a system call is called makes it difficult to meet the performance requirements.

[0010] An object of the present invention is to provide a behavior monitoring device, a behavior monitoring method, and a behavior monitoring program that can satisfy the performance requirements of a target system when obtaining statistical information on system calls.

[0011] In order to solve the above problem, the behavior monitoring device of the present invention comprises a filter unit that acquires system call invocation information when a system call is invoked, a statistical data management unit that records and manages the system call invocation information, a filter management unit that controls the enabling / disabling of the filter unit's function of acquiring the system call invocation information, and a monitoring unit that monitors the number of system call invocations based on the system call invocation information from the statistical data management unit to detect attacks or abnormalities.

[0012] According to the present invention, the number of times information acquisition processing related to system call invocation information is performed is reduced, thereby mitigating adverse effects on performance such as delays caused by acquiring system call invocation information, and enabling the performance requirements of the target system to be met.

[0013] 1 is a diagram illustrating the functions and configuration of a behavior monitoring device of an embodiment; FIG. 2 is a diagram illustrating the hardware configuration of a behavior monitoring device of an embodiment; FIG. 3 is a sequence diagram illustrating the operation of a behavior monitoring device of an embodiment; FIG. 4 is a flow diagram for controlling a behavior monitoring device; FIG. 5 is a diagram illustrating an example of the change over time in the number of system call invocations under normal circumstances when there are no attacks or abnormalities in the case of 1 / n sampling; FIG. 6 is a diagram illustrating the reduction of n in 1 / n sampling so as to expand the filter effective interval; FIG. 7 is a diagram illustrating the increase of n in 1 / n sampling so as to reduce the filter effective interval; FIG. 8 is a schedule diagram illustrating the filter effective intervals of system calls A, B, C, and D with thick rectangles; and FIG. 9 is a diagram illustrating the functions and configuration of another behavior monitoring device of an embodiment.

[0014] A behavior monitoring device according to an embodiment of the present invention does not execute information acquisition processing (hooking) for every system call, but instead enables information acquisition processing (hooking) only for a certain percentage of the time interval, and uses the information acquired during the valid interval to supplement the call status for the entire interval, thereby detecting attacks and abnormalities. This will be described in detail below with reference to the drawings.

[0015] 1 is a diagram illustrating the functions and configuration of a behavior monitoring device according to an embodiment. The behavior monitoring device 1 includes a filter unit 4 that acquires system call invocation information when an application 3 invokes a system call, a statistical data management unit 8 that records and manages the system call invocation information acquired by the filter unit 4, a filter management unit 6 that controls the enabling / disabling of the system call invocation information acquisition function of the filter unit 4, and a monitoring unit 7 that monitors the number of system call invocation information pieces recorded in the statistical data management unit 8 (the number of system call invocations per unit time) to detect attacks and abnormalities.

[0016] The behavior monitoring device 1 operates integrally with an operating system (OS) 2 and an application 3 in a computer on which the OS 2 runs. The behavior monitoring device 1 may also be one of the functions of the OS 2.

[0017] Specifically, the behavior monitoring device 1 of the embodiment is realized by a computer 200 shown in the hardware configuration diagram of Fig. 2. The computer 200 includes a central processing unit (CPU) 201, a read-only memory (ROM) 202, a random access memory (RAM) 203, a hard disk drive (HDD) 204, an input / output interface (I / F) 205, a communication I / F 206, and a media I / F 207.

[0018] The CPU 201 operates based on programs stored in the ROM 202 or the HDD 204, and controls each unit of the computer 200. The ROM 202 stores a boot program executed by the CPU 201 when the computer 200 is started up, programs related to the hardware of the computer 200, and the like.

[0019] The CPU 201 controls an input device 210 such as a mouse or keyboard, and an output device 211 such as a display or printer, via an input / output I / F 205. The CPU 201 acquires data from the input device 210 via the input / output I / F 205, and outputs generated data to the output device 211. Note that a GPU (Graphics Processing Unit) or the like may be used as a processor together with the CPU 201.

[0020] The HDD 204 stores programs executed by the CPU 201 and data used by the programs. The communication I / F 206 receives data from other devices via a communication network (e.g., NW (Network) 220) and outputs the data to the CPU 201, and also transmits data generated by the CPU 201 to other devices via the communication network.

[0021] The media I / F 207 reads a program or data stored in the recording medium 212 and outputs it to the CPU 201 via the RAM 203. The CPU 201 loads a program related to a target process from the recording medium 212 onto the RAM 203 via the media I / F 207, and executes the loaded program. The recording medium 212 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase Change Rewritable Disc), a magneto-optical recording medium such as an MO (Magneto Optical Disc), a magnetic recording medium, a semiconductor memory, or the like.

[0022] For example, when a computer 200 or the like functions as the behavior monitoring device 1 of the embodiment, a CPU 201 of the computer 200 executes a program loaded onto a RAM 203 to realize the functions of each processing unit of the behavior monitoring device 1. The HDD 204 also functions as a statistical data management unit 8 that records and manages system call invocation information, and the data in the RAM 203 is stored in the HDD 204.

[0023] The CPU 201 reads and executes a program related to a target process from the recording medium 212. Alternatively, the CPU 201 may read a program related to a target process from another device via a communication network (NW 220).

[0024] In detail, the filter unit 4 can be realized by utilizing the extended Berkley Packet Filter (eBPF), which is provided as a function of the Linux (registered trademark) and Windows (registered trademark) kernel and is a framework that securely and dynamically hooks system calls. Specifically, the filter unit 4 operates as a kernel function by an eBPF program in which the functions of the filter unit 4 are written in C language.

[0025] Next, the operation of the behavior monitoring device 1 according to the embodiment will be described with reference to the sequence diagram of FIG.

[0026] In step S1, the filter management unit 6 of the behavior monitoring device 1 sets a sampling rate, which is the time ratio of the acquisition period when the filter unit 4 acquires system call invocation information. Also in step S1, the monitoring unit 7 sets a sampling rate indicating the timing for monitoring the number of system call invocations.

[0027] In step S2, the filter management unit 6 notifies the filter unit 4 of a "filter enable" instruction to enable the system call hook function of the filter unit 4 based on the set sampling rate. As a result, the filter unit 4 starts monitoring system call invocations.

[0028] In step S3, when the application 3 invokes (issues) a system call, the filter unit 4 hooks it and acquires the system call invocation information. After that, the system call issued by the application 3 reaches the system call processing unit 5, which provides the application 3 with the specified function of the OS 2.

[0029] The invocation information of a system call includes, for example, the name of the application that made the call, the type of the system call that was called, and the timestamp of the call. As will be explained with reference to Fig. 7, when monitoring each system call, it is necessary to include at least the type of the system call that was called as the invocation information of the system call.

[0030] In step S4, the statistical data management unit 8 acquires and records system call invocation information from the filter unit 4.

[0031] In step S5, when the application 3 invokes (issues) a system call, the filter unit 4 hooks this because the hook function is enabled, and obtains the system call invocation information.

[0032] In step S6, the statistical data management unit 8 acquires and records the system call invocation information from the filter unit 4. The statistical data management unit 8 also calculates the number of acquired system call invocation information per unit time as the system call invocation count.

[0033] In step S7, the filter management unit 6 notifies the filter unit 4 of a "filter disable" instruction to disable the system call hook function of the filter unit 4 based on the set sampling rate. As a result, the filter unit 4 ends monitoring of system call invocations.

[0034] In step S8, after the filter unit 4 is notified of filter disablement in step S7, the monitoring unit 7 acquires the number of system call invocations from the statistical data management unit 8, monitors the change over time in the number of system call invocations, and detects attacks or abnormalities. That is, the monitoring unit 7 determines that an attack or abnormality has been detected when the change over time exceeds a predetermined value. Furthermore, the monitoring unit 7 determines that an attack or abnormality has been detected when the number of system call invocations increases by a predetermined percentage compared to normal times.

[0035] In step S9, the application 3 invokes (issues) a system call and notifies the system call processing unit 5. At this time, the filter unit 4 does not hook the system call because the hook function is disabled.

[0036] In steps S10, S11, and S12, the filter unit 4 does not hook the invocation (issuance) of a system call from the application 3, as in step S9.

[0037] In step S13, the filter management unit 6 notifies the filter unit 4 of a "filter enable" instruction to enable the system call hook function of the filter unit 4 based on the set sampling rate. As a result, the filter unit 4 starts monitoring system call invocations.

[0038] In step S14, when the application 3 invokes (issues) a system call, the filter unit 4 hooks it, obtains the system call invocation information, and notifies the system call processing unit 5 of the system call issued by the application 3.

[0039] In step S15, the statistical data management unit 8 acquires and records the system call invocation information from the filter unit 4. The statistical data management unit 8 also calculates the number of acquired system call invocation information per unit time as the system call invocation count.

[0040] In step S16, the filter management unit 6 notifies the filter unit 4 of a "filter disable" instruction to disable the system call hook function of the filter unit 4 based on the set sampling rate. As a result, the filter unit 4 ends monitoring of system call invocations.

[0041] In step S17, after the filter unit 4 is notified of filter disablement in step S16, the monitoring unit 7 acquires the number of system call invocations from the statistical data management unit 8, monitors the change over time in the number of system call invocations, and detects attacks or abnormalities. That is, the monitoring unit 7 determines that an attack or abnormality has been detected when the change over time exceeds a predetermined value. Furthermore, the monitoring unit 7 determines that an attack or abnormality has been detected when the number of system call invocations increases by a predetermined percentage compared to normal times.

[0042] As described above, the filter unit 4 hooks only the system call calls in steps S3 and S5 out of the system call calls in steps S3, S5, S9, S10, S11, and S12 in accordance with the sampling rate setting set in step S1, thereby reducing the total delay due to the hooking of the system call calls and minimizing performance degradation.

[0043] Fig. 4 is a flow diagram showing how to control the behavior monitoring device 1 described in Fig. 3. In step S41, the behavior monitoring device 1 sets the valid period and invalid period of the filter function of the filter unit 4 to the filter management unit 6 and the monitoring unit 7 as a sampling rate, which is the time ratio in a unit time of the period during which the filter unit 4 acquires system call invocation information.

[0044] In step S42, the filter management unit 6 notifies the filter unit 4 of a "filter enable" instruction that enables the system call hook function of the filter unit 4, and starts monitoring the system call invocation in the filter unit 4.

[0045] In step S43, the filter management unit 6 determines whether the effective period of the filter function of the filter unit 4 has ended. If it has not ended (No in S43), the process proceeds to step S44; if it has ended (Yes in S43), the process proceeds to step S47.

[0046] In step S44, the filter unit 4 detects whether the application has invoked (issued) a system call, and if it has (Yes in S44), proceeds to step S45, and if it has not (No in S44), return to step S43.

[0047] In step S45, the filter unit 4 hooks the system call made by the application and performs a hook process to acquire the system call invocation information. Then, the statistical data management unit 8 acquires the system call invocation information from the filter unit 4 and records it.

[0048] In step S46, the system call issued by the application 3 reaches the system call processing unit 5 and is processed. The system call processing unit 5 provides the function of OS 2 specified as the system call to the application 3, and the process returns to step S43.

[0049] In step S47, the filter management unit 6 notifies the filter unit 4 of a "filter disable" instruction to disable the system call hook function of the filter unit 4 based on the set sampling rate, and the filter unit 4 ends monitoring of system call invocations.

[0050] In step S48, the monitoring unit 7 acquires the number of system call invocations from the statistical data management unit 8, monitors the change over time in the number of system call invocations, and detects attacks or abnormalities. That is, the monitoring unit 7 determines that an attack or abnormality has been detected when the change over time compared to normal times exceeds a predetermined value. The monitoring unit 7 also determines that an attack or abnormality has been detected when the number of system call invocations increases by a predetermined percentage compared to normal times.

[0051] In step S49, the filter management unit 6 determines whether the invalid period of the filter function of the filter unit 4 has ended. If it has not ended (No in S49), the process proceeds to step S410; if it has ended (Yes in S49), the process proceeds to step S47.

[0052] In step S410, the filter unit 4 detects whether the application has invoked (issued) a system call, and if it has (Yes in S410), proceeds to step S411, and if it has not (No in S410), return to step S49.

[0053] In step S411, the system call issued by application 3 reaches the system call processing unit 5, where the system call is processed. The system call processing unit 5 provides the function of OS 2 specified as the system call to application 3, and the process returns to step S49.

[0054] In step S412, the behavior monitoring device 1 determines whether to end behavior monitoring of the computer, and if not (No in S412), returns to step S42 and continues monitoring during the valid period of the system call invocation of the application 3. If monitoring is to end (Yes in S412), the process ends.

[0055] 3 and 4, the behavior monitoring device 1 of the embodiment acquires the number of system calls in the set filter effective section and detects attacks and abnormalities based on the acquired number of system calls, assuming that the number of system calls by the application 3 is approximately constant.

[0056] Next, a case where the system call invocation of the application 3 changes over time will be described.

[0057] 5 shows an example of the change over time in the number of system calls under normal circumstances when there are no attacks or abnormalities, in the case of 1 / n sampling. In 1 / n sampling, when the filter-enabled section in which system calls are hooked is set to t, the filter-disabled section is set to (n-1)t, and the number of system calls in the filter-disabled section is assumed to be equal to the number of system calls in the filter-enabled section.

[0058] In the case of the time variation of the number of system calls shown in Figure 5 (dotted line), the difference between the calculated number of system calls and the actual value becomes large, especially in the filter disabled section. If the difference is larger than the threshold for determining whether an increase in the number of system calls is due to an attack or an abnormality, the attack or abnormality cannot be detected. How to deal with such a case will be explained next.

[0059] 6A shows that when the change in the number of system calls over time is equal to or greater than a preset threshold, i.e., when the number of system calls fluctuates greatly over time, the filter effective interval shown by the dashed rectangle is expanded (the time setting is increased to widen the filter effective interval), and n in the 1 / n sampling is reduced. This reduces the difference between the calculated number of system calls and the actual value, thereby preventing attacks and anomalies from going undetected.

[0060] Contrary to FIG. 6A , FIG. 6B shows that when the change over time in the number of system call invocations is smaller than a preset threshold, i.e., when the fluctuation over time in the number of system call invocations is small, the filter effective interval shown by the dashed rectangle is reduced (the time setting is reduced to narrow the filter effective interval), and n in the 1 / n sampling is increased.

[0061] Because the change in the number of system calls over time is small, reducing the filter effective period has little impact on the difference in the number of system calls due to attacks or abnormalities. By reducing the time setting for the filter effective period, the number of hook processes that obtain system call invocation information decreases, reducing the total delay and performance degradation.

[0062] Since there are multiple types of system calls and multiple applications that call them, a scheduler may be provided that hooks system call calls while avoiding overlapping of the valid periods of filters for different system calls and overlapping of the valid periods of different types of filters for the same system call.

[0063] 7 is a schedule diagram in which the filter effective intervals for each of system calls A, B, C, and D are indicated by bold rectangles. By providing a filter effective interval for each system call and monitoring the change in the number of system calls over time, the change in the system calls themselves over time is dispersed, making it easier to detect an increase in system calls due to an attack or an abnormality.

[0064] Figure 8 is a diagram explaining the functions and configuration of a behavior monitoring device that controls the expansion / reduction of the filter effective section in accordance with the change in the number of system call invocations over time as described in Figures 6A and 6B, and that provides a filter for each system call as described in Figure 7.

[0065] The behavior monitoring device 1 in Fig. 8 is configured such that a sampling rate control unit 9 is provided in the behavior monitoring device 1 in Fig. 1, and the filter management unit 6 of the behavior monitoring device 1 in Fig. 1 includes a scheduler 61. Description of the same components as those in the behavior monitoring device 1 in Fig. 1 will be omitted.

[0066] The sampling rate control unit 9 controls the expansion / reduction of the filter effective interval in accordance with the change over time in the number of system call invocations described with reference to Figures 6A and 6B. During normal times when no attacks or abnormalities are present, the sampling rate control unit 9 sets the time of the filter effective interval so that attacks and abnormalities can be detected from the change over time in the number of system call invocations. The sampling rate control unit 9 may also change the cycle of the filter effective interval.

[0067] The scheduler 61 sets a filter effective period for each system call described in Fig. 7 so that the filter effective periods do not overlap. The sampling rate control unit 9 sets the time for the filter effective period.

[0068] The monitoring unit 7 monitors the change over time in the number of system calls for each system call, and determines that an attack or abnormality has been detected when the change over time in the number of system calls for any system call exceeds a predetermined value, or when the number of system calls increases by a predetermined percentage compared to normal times.

[0069] In the above, we have explained that adverse effects on performance, such as delays, can be mitigated by hooking system calls only within the sampled filter-enabled section. However, in situations where there is ample host resources, such as CPU usage, it is also possible to hook all system calls to detect attacks and abnormalities.

[0070] The behavior monitoring device and behavior monitoring method according to the present invention are described below. The behavior monitoring device 1 according to the present invention comprises a filter unit 4 that acquires system call invocation information when a system call is invoked, a statistical data management unit 8 that records and manages the system call invocation information, a filter management unit 6 that controls the enabling / disabling of the filter unit 4's function of acquiring system call invocation information, and a monitoring unit 7 that monitors the number of system call invocations based on the system call invocation information from the statistical data management unit 8 to detect attacks or abnormalities.

[0071] In addition, the behavior monitoring method of the present invention is a behavior monitoring method for a behavior monitoring device, and includes a step of determining whether or not the system call hook function is in an effective interval and acquiring system call call information, and a step of detecting attacks or abnormalities based on changes in the number of calls over time according to the system call call information.

[0072] The behavior monitoring method also includes a step of increasing or decreasing the time setting of the filter effective interval so that an attack or an abnormality can be detected based on the change in the number of system calls over time.

[0073] The present invention is not limited to the above-described embodiments, and many modifications can be made by a person skilled in the art within the technical concept of the present invention.

[0074] REFERENCE SIGNS LIST 1 Behavior monitoring device 2 OS 3 Application 4 Filter unit 5 System call processing unit 6 Filter management unit 61 Scheduler 7 Monitoring unit 8 Statistical data management unit 9 Sampling rate control unit

Claims

1. A behavior monitoring device comprising: a filter unit that acquires system call invocation information when a system call is invoked; a statistical data management unit that records and manages the system call invocation information; a filter management unit that controls the enabling / disabling of the filter unit's function of acquiring the system call invocation information; and a monitoring unit that monitors the number of system call invocations based on the system call invocation information from the statistical data management unit to detect attacks or abnormalities.

2. A behavior monitoring method for a behavior monitoring device, comprising the steps of: determining whether or not a system call hook function is in an effective interval and acquiring system call call information; and detecting attacks or abnormalities based on changes over time in the number of calls in the system call information.

3. A behavior monitoring method according to claim 2, including a step of increasing or decreasing the time setting of the filter effective interval so that attacks or abnormalities can be detected based on changes over time in the number of system calls.

4. A behavior monitoring program for causing a computer to function as: a filter means for acquiring system call invocation information when a system call is made; a statistical data management means for recording and managing said system call invocation information; a filter management means for controlling the enabling / disabling of the filter means' function of acquiring said system call invocation information; and a monitoring means for detecting attacks or abnormalities by monitoring the number of system call invocations based on the system call invocation information of said statistical data management means.

Images