Monitoring device and program

Abstract

A monitoring device (100) comprises: an acquisition unit (112) that, when a process calls a system call (SC), acquires an SC list obtained by combining the SC and SCs that have been called in the past as a comparison target list; a comparison unit (113) that, when the process is a comparison target process, compares the comparison target list that has been called by the process with an SC list included in an abnormality list indicating an abnormal SC list; a determination unit (114) that determines, by using a determination model (122), whether the comparison target list that has been called by the process is normal or abnormal; and a reflection unit (115) that uses, as the comparison target process, a process that has called the comparison target list when the comparison target list is abnormal.

Description

Monitoring device and program

[0001] The present invention relates to a monitoring device and a program for monitoring system calls made by an application.

[0002] In recent years, attention has been focused on virtual network infrastructure, which uses virtualization technology to build network systems on general-purpose servers. By introducing virtual network infrastructure, telecommunications carriers no longer need to procure dedicated hardware, and can flexibly allocate, move, and delete resources through software control. This allows for significant cost reductions.

[0003] The use of container technology is becoming more widespread in virtual network infrastructure, particularly due to its cost and operational flexibility. Container technology allows containers owned by multiple tenants to share the same OS and access common resources. This makes security extremely important, as it constantly monitors and detects suspicious behavior and anomalies, and takes measures against threats.

[0004] Applications, including containers, access the kernel using system calls to use memory and other shared resources. However, if all system calls used are permitted, the security of the entire system will be at risk. For this reason, methods are currently used to restrict the system calls that can be used (called). One example of such a restriction function is seccomp (secure computing mode). This seccomp function allows you to set whether or not to permit each individual system call called by an application.

[0005] There are two problems with filtering technology that allows or disallows individual system calls. The first is that there is a trade-off between security strength and system availability. If many system calls are disallowed and restrictions are tightened, security improves but availability decreases. Conversely, if restrictions are relaxed, availability improves but security decreases. The second problem is that even permitted system calls can still be attacked if combined appropriately.

[0006] In order to address such problems, Non-Patent Document 1 proposes filtering that takes into account the invocation order of system calls (sequence pattern, system call sequence) instead of filtering individual system calls.

[0007] Somin Song, et al., "On the Value of Sequence-based System Call Filtering for Container Security," 2023 IEEE 16th International Conference on Cloud Computing (CLOUD), pp.296-307.

[0008] Non-Patent Document 1 describes a method for extracting a sequence of system calls that may pose a threat. Detecting a sequence of system calls extracted from the system calls of an application enables more accurate detection of threats than setting permission / prohibition for each individual system call. However, the processing cost of constantly monitoring all applications is high, posing a major practical problem. The present invention has been made in light of this background, and aims to enable efficient monitoring of multiple system call invocations.

[0009] In order to solve the above-mentioned problems, the monitoring device of the present invention includes an acquisition unit that, when a process calls a system call that requests OS processing, acquires, as a comparison target list, a system call list that combines the called system call and system calls that the process has called in the past; a memory unit that stores an abnormality list that indicates an abnormal system call list that includes one or more system calls; a comparison unit that, when the process is a comparison target process, compares the comparison target list called by the process with a system call list included in the abnormality list to determine whether the comparison target list is abnormal; a determination unit that, when the process is not the comparison target process, determines whether the comparison target list called by the process is normal or abnormal using a predetermined determination model; and a reflection unit that, when the determination unit determines that the comparison target list is abnormal, designates the process that called the comparison target list as the comparison target process.

[0010] According to the present invention, it is possible to efficiently monitor multiple invocations of a system call.

[0011] FIG. 1 is a functional block diagram of a monitoring device according to the present embodiment. FIG. 2 is a data configuration diagram of a call history database according to the present embodiment. FIG. 3 is a data configuration diagram of an anomaly list according to the present embodiment. FIG. 4 is a data configuration diagram of a monitoring information database according to the present embodiment. FIG. 5 is a sequence diagram of a matching process according to the present embodiment. FIG. 6 is a sequence diagram of a determination process according to the present embodiment. FIG. 7 is a flowchart of a matching target change process according to the present embodiment. FIG. 8 is a hardware configuration diagram showing an example of a computer that realizes the functions of the monitoring device according to the above-mentioned embodiment.

[0012] <Overview of Monitoring Device> An overview of the monitoring device in a mode (embodiment) for carrying out the present invention will be described below. The monitoring device monitors system calls invoked by applications including containers. The monitoring device compares a system call sequence, including past calls, with an anomaly list, which is a list of system call sequences that pose a threat. If the system call sequence is found in the anomaly list, the monitoring device executes a predetermined response process. Examples of the predetermined response process include recording the system call invocation in a monitoring log, returning an error without processing the call, or stopping the calling application. Note that hereinafter, an application is also referred to as an application process or simply as a process.

[0013] Not all processes are necessarily targets for matching the system call sequences they invoke against the anomaly list. For example, if the monitoring device determines that a process is normal, the monitoring device will not consider the process as a target for matching if the load on the monitoring device is heavy. Machine learning techniques, for example, are used to determine whether a process is normal. Such a monitoring device can reduce the load of matching system call sequences against the anomaly list, enabling efficient monitoring of system call invocations.

[0014] Configuration of Monitoring Device Fig. 1 is a functional block diagram of a monitoring device 100 according to this embodiment. The monitoring device 100 is a computer and includes a control unit 110, a storage unit 120, and an input / output unit 180. User interface devices such as a display, keyboard, and mouse are connected to the input / output unit 180. The input / output unit 180 may include a communication device and be capable of transmitting and receiving data to and from other devices. For example, the input / output unit 180 transmits and receives data to and from a terminal that uses a network service provided by an application (see application function unit 111, described below) running on the monitoring device 100.

[0015] <Monitoring Device: Storage Unit> The storage unit 120 includes storage devices such as a read-only memory (ROM), a random access memory (RAM), and a solid-state drive (SSD). The storage unit 120 stores application data 131, an application program 132, a call history database 140, an anomaly list 150, a monitoring information database 160, a monitoring log 121, a judgment model 122, and a program 128. The various contents stored in the storage unit 120 may be stored in an external storage device such as a cloud server and loaded as needed. The program 128 describes the processes executed by the acquisition unit 112, the collation unit 113, the judgment unit 114, and the reflection unit 115 included in the control unit 110 (described later).

[0016] <Storage Unit: Application Data / Application Program> The application data 131 is data accessed by an application (see the application function unit 111 described below) running on the monitoring device 100. The application program 132 is the program of that application. When multiple applications run on the monitoring device 100, there is application data 131 and an application program 132 for each application. Note that each application included in a container may be considered to be the application function unit 111.

[0017] <Storage Unit: Call History Database> Fig. 2 is a data configuration diagram of the call history database 140 according to this embodiment. The call history database 140 records the call history of system calls for each application (process). Applications are identified by process identification information (referred to as "PID" in Fig. 2). In the example of Fig. 2, the application with process identification information "23" invokes the following system calls in this order: system call 53, system call 64, system call 2, system call 75, and system call 93. Note that in Fig. 2 and subsequent figures, "SC" stands for system call.

[0018] <Storage Unit: Anomaly List> Fig. 3 is a data configuration diagram of the anomaly list 150 according to this embodiment. The anomaly list 150 is a list of system call sequences that may pose a threat (abnormal) among the system call sequences invoked by applications, and their identification information (identification numbers). A threat refers to an attack or a precursor to an attack, such as interfering with the execution of the OS or other applications of the monitoring device 100, or data theft.

[0019] When the monitoring device 100 detects an invocation of a system call in the anomaly list 150, it executes a predetermined response process. The predetermined response process may include recording the system call invocation in a monitoring log, returning an error without processing the call, or stopping the called application. In the following, the predetermined response process is assumed to be returning an error without processing (executing) the call and recording it in a monitoring log (see monitoring log 121 described below).

[0020] 3, an application (process) invokes the system calls in the order of system call 3, system call 23, system call 15, and system call 64. In this case, the monitoring device 100 returns an error in response to the invocation of this last system call, system call 64, and records this in the monitoring log 121.

[0021] <Storage Unit: Monitoring Information Database> Fig. 4 is a data configuration diagram of the monitoring information database 160 according to this embodiment. The monitoring information database 160 includes information on the monitoring level and the appropriateness of the matching target for each application (process) to be monitored. Note that not all applications running on the monitoring device 100 are necessarily monitored. The monitoring targets included in the monitoring information database 160 may be, for example, applications (processes) that provide network services, or other applications that provide services used by the applications.

[0022] The monitoring level is either "constant check" or "as needed check." In the case of constant check, the sequence of system calls called by an application is constantly checked against the anomaly list 150. In the case of as needed check, the sequence of system calls called by an application is checked against the anomaly list 150 when a predetermined condition is met. An example of the predetermined condition is that the load on the monitoring device 100 is equal to or less than a predetermined value.

[0023] The matching target indicates whether or not the system call sequence currently invoked by the application is to be matched against the anomaly list 150 ("YES" / "NO"). In Fig. 4, the predetermined condition is not met (for example, the load on the monitoring device 100 exceeds a predetermined value), and the "on-demand matching" application is not a matching target ("NO"). If the predetermined condition is met, all matching targets become "YES," and the application including the on-demand matching application becomes a matching target.

[0024] 1, the description of the storage unit 120 will continue. The monitoring log 121 records logs related to call sequences in the anomaly list 150 among the system calls made in the monitoring device 100. The logs include identification information of the called application (e.g., process identification information), identification information of the call sequence, the time of the call, and the like.

[0025] <<Storage Unit: Determination Model>> The determination model 122 is a machine learning model used to determine whether an application is normal or abnormal, using a system call sequence of a predetermined length called by the application as an explanatory variable (input). The determination model 122 is a machine learning model constructed by unsupervised learning using, for example, a system call sequence of an application that has run normally in a safe, threat-free environment as learning data. By using such a determination model 122, it is possible to determine that a system call sequence that is considered to be different from the learned system call sequence is abnormal.

[0026] <Monitoring Device: Control Unit> The control unit 110 is configured to include a CPU (Central Processing Unit) and is equipped with an application function unit 111, an acquisition unit 112, a collation unit 113, a determination unit 114, and a reflection unit 115. The control unit 110 may be configured to include a GPU (Graphics Processing Unit), an NPU (Neural (network) Processing Unit), an FPGA (Field Programmable Gate Array), an ASIC (Application Specific Integrated Circuit), etc.

[0027] <<Control Unit: Application Function Unit>> The application function unit 111 is a process on the OS (not shown) of the monitoring device 100 that executes application processing. The application function unit 111 may be in the form of a container. A series of system calls called by the application function unit 111 is monitored. Note that a system call is an instruction (function call) by which an application calls a function of the OS (kernel). Note that the number of application function units 111 is not limited to one; generally, multiple application function units 111 are running.

[0028] <<Controller: Acquisition Unit>> The acquisition unit 112 acquires a system call invoked by the application function unit 111. The acquisition unit 112 operates by being invoked by, for example, the OS (kernel) of the monitoring apparatus 100, and hooks and acquires the system call invoked by the application function unit 111.

[0029] First, a case will be described in which the application function unit 111 is the target of matching (see FIG. 4 ) (“YES”). When the application function unit 111 invokes a system call, the acquisition unit 112 records which system call was invoked for each application function unit 111 (process) in the call history database 140 (see FIG. 2 ). Furthermore, if the application function unit 111 is the target of matching (see FIG. 4 ), the acquisition unit 112 sends the system call sequence (call history, matching target list) in the call history database 140 to the matching unit 113, which will be described later. The matching unit 113 then sends back the result of matching the call history with the anomaly list 150. Note that a successful match means that the call history (the sequence of invoked system calls) is included in the anomaly list 150, and is a call that could pose a threat.

[0030] If the comparison is successful, the acquisition unit 112 determines that the invoked system call is not permitted, returns an error as the return value of the system call to the application function unit 111, and records the error in the monitoring log 121. If the comparison is unsuccessful, the acquisition unit 112 determines that the invoked system call is permitted, and returns the result of the system call invocation to the application function unit 111. The length of the system call invocation history may be, for example, the maximum length of the system call sequence in the anomaly list 150.

[0031] Next, a case where the application function unit 111 is not the target of comparison (see FIG. 4 ) ("NO") will be described. In this case, the acquisition unit 112 sends the system call sequence called by the application function unit 111 to the determination unit 114 during the determination period. The determination period is a period of a predetermined length that starts at a predetermined timing. For example, the determination period is a one-minute period every ten minutes. The processing of the determination unit 114 will be described later.

[0032] <<Control Unit: Collation Unit>> The collation unit 113 collates the system call sequence (call history) sent by the acquisition unit 112 with each system call sequence in the anomaly list 150 to determine whether or not an anomaly exists. The collation unit 113 sends back to the acquisition unit 112 the presence or absence of a matching system call sequence as a collation result (success / failure). Note that a system call sequence is sent to the collation unit 113 when the application function unit 111 that called the system call sequence is the target of collation (see the target of collation in the monitoring information database 160 shown in FIG. 4 ).

[0033] For example, suppose the acquisition unit 112 has sent system call 93, system call 3, system call 51, system call 63, and system call 43 (see the third call history in FIG. 2). The last system call, system call 43, is the system call currently being called by the application function unit 111. A subsequence, including the tail, of this system call sequence matches the third system call sequence in the anomaly list 150 (see FIG. 3), and the collation unit 113 determines that the collation is successful. In this way, the collation unit 113 verifies whether the subsequence, including the tail, matches the system call sequence in the anomaly list 150.

[0034] <<Controller: Determination Unit>> The determination unit 114 determines whether the system call sequence received from the acquisition unit 112 is normal or abnormal using the determination model 122. Note that the determination unit 114 determines the system call sequence when the application function unit 111 that called the system call sequence is not the target of matching (see FIG. 4 ).

[0035] <<Controller: Reflection Unit>> When the determination unit 114 determines that a system call sequence is abnormal, the reflection unit 115 sets the monitoring level (see FIG. 4 ) of the application function unit 111 that called the system call sequence to "constant verification" and the verification target to "YES." In other words, if the system call sequence called by the application function unit 111 is abnormal, the verification unit 113 will verify subsequent system call sequences called by the application function unit 111.

[0036] Furthermore, if the load on the monitoring device 100 is equal to or less than a predetermined value, the reflection unit 115 sets "YES" to all matching targets in the monitoring information database 160 (see FIG. 4). If the load on the monitoring device 100 exceeds a predetermined value, the reflection unit 115 sets "NO" to matching targets of the application function unit 111 whose monitoring level in the monitoring information database 160 is "constant matching."

[0037] <<Matching Process>> Fig. 5 is a sequence diagram of the matching process according to this embodiment. The matching process is a process related to a system call called by the application function unit 111 that is the target of matching (see Fig. 4). The process of Fig. 5 is executed each time the application function unit 111 that is the target of matching calls a system call. Note that the process (determination process) related to a system call called by an application function unit 111 that is not the target of matching will be described later with reference to Fig. 6. In Fig. 5 and subsequent figures, the application function unit is referred to as an "AP function unit" and the system call is referred to as an "SC."

[0038] In step S11, the application function unit 111 invokes a system call. In step S12, the invocation of the system call in step S11 is notified to the acquisition unit 112 (the acquisition unit 112 is invoked) by, for example, a function of the OS (kernel) of the monitoring apparatus 100. The notification includes identification information (process identification information) of the application function unit 111 that invoked the system call.

[0039] In step S13, the acquisition unit 112 records the invoked system call in the call history corresponding to the process identification information in the call history database 140. In step S14, the acquisition unit 112 sends the system call sequence in the call history corresponding to the process identification information to the collation unit 113.

[0040] In step S15, the collation unit 113 compares the received system call sequence with the system call sequence in the anomaly list 150. In step S16, the collation unit 113 sends the comparison result to the acquisition unit 112. In step S17, if the comparison result is successful (step S17 → success), the acquisition unit 112 proceeds to step S18, and if the comparison result is unsuccessful (step S17 → failure), the acquisition unit 112 proceeds to step S20.

[0041] In step S18, the acquisition unit 112 records the current time, process identification information, system call invocation history, and the like in the monitoring log 121. In step S19, the acquisition unit 112 returns an error as a result of the system call invocation to the application function unit 111 by using, for example, a function of the OS (kernel) of the monitoring apparatus 100.

[0042] In step S20, the acquisition unit 112 invokes a system call. In step S21, the acquisition unit 112 returns the result of the system call invoked in step S20 to the application function unit 111 using, for example, a function of the OS (kernel) of the monitoring apparatus 100.

[0043] <Determination Process> Fig. 6 is a sequence diagram of the determination process according to this embodiment. The determination process is a process related to a system call sequence called by an application function unit 111 that is not a target of matching (see Fig. 4) during the determination period. The process in Fig. 6 is executed every time an application function unit 111 that is not a target of matching calls a system call during the determination period. The monitoring level of the application function unit 111 that is not a target of matching is "constant matching."

[0044] Steps S31 to S33 are the same as steps S11 to S13 (see FIG. 5). In step S34, the acquisition unit 112 sends the system call sequence in the call history corresponding to the process identification information to the determination unit 114. In step S35, the determination unit 114 determines whether the system call sequence is normal or abnormal.

[0045] In step S36, if the determination result in step S35 is normal (step S36 → normal), the determination unit 114 proceeds to step S38. If the determination result in step S35 is abnormal (step S36 → abnormal), the determination unit 114 proceeds to step S37. In step S37, the reflection unit 115 sets the monitoring level of the application function unit 111 (see FIG. 4) to "constant verification" and the verification target to "YES." Steps S38 to S39 are the same processes as steps S20 to S21 (see FIG. 5).

[0046] <<Comparison Target Change Processing>> Fig. 7 is a flowchart of the comparison target change processing according to this embodiment. The comparison target change processing is processing that is executed at a predetermined timing, for example, periodically.

[0047] In step S41, if the load on the monitoring device 100 is equal to or less than a predetermined value (step S41→YES), the reflection unit 115 proceeds to step S42. If the load on the monitoring device 100 is greater than the predetermined value (step S41→NO), the reflection unit 115 proceeds to step S43.

[0048] In step S42, the reflection unit 115 sets "YES" to all matching targets in the monitoring information database 160 (see FIG. 4). In step S43, the reflection unit 115 sets "NO" to matching targets of application function units 111 whose monitoring level in the monitoring information database 160 is "constant matching". In other words, a system call sequence called by an application function unit 111 whose monitoring level is "constant target" becomes a matching target to be matched against the anomaly list 150. A system call sequence called by an application function unit 111 whose monitoring level is "constant target" is judged by the judgment unit 114 as normal or abnormal.

[0049] <Features of the Monitoring Device> The monitoring device 100 monitors system call invocations for each application function unit 111. When the monitoring device 100 detects a call sequence in the abnormality list 150 (see step S17 → success in FIG. 4 ), the monitoring device 100 disallows the system call by failing the invocation (see step S19).

[0050] When the load on the monitoring device 100 is low, the monitoring device 100 checks the system call sequences invoked for all application function units 111 in the monitoring information database 160 (see FIG. 4 ) against the anomaly list 150. When the load on the monitoring device 100 is high, the monitoring device 100 checks the system call sequences invoked for application function units 111 whose monitoring level is "constant check" against the anomaly list 150. In this way, expanding or reducing the objects to be checked depending on the load on the monitoring device 100 enables efficient monitoring of system call invocations.

[0051] Furthermore, when the monitoring device 100 determines that the sequence of system calls called by the application function unit 111 is abnormal, it causes the collation unit 113 to collate the sequence of system calls called by the application function unit 111 (step S36 → abnormal, see step S37). In other words, when the monitoring device 100 determines that the operation is different from normal, it compares the sequence of system calls with the anomaly list 150, thereby monitoring the application function unit 111 with a more accurate method.

[0052] <<Modification: System Call Sequence>> In the above embodiment, the collation unit 113 collates a system call sequence, including the calling order of the system calls, with the anomaly list 150. The collation unit 113 may also perform collation as a system call group (list to be collated), which is a collection (set) of system calls ignoring the calling order. In this case, the anomaly list 150 is also a list of abnormal system calls ignoring the calling order. The system call sequence and the system call group are collectively referred to as the system call list.

[0053] The same applies to the determination unit 114. The determination model 122 is a machine learning model used to determine whether an application is normal or abnormal, using a set of system calls called by the application as explanatory variables. The determination unit 114 may determine normality or abnormality using such a determination unit 114.

[0054] <<Modification: Number of Monitoring Levels>> In the above-described embodiment, there are two monitoring levels: "constant matching" and "occasional matching." This is not limiting, and there may be three or more monitoring levels. For example, the judgment results of the judgment model 122 are assumed to be three: "normal," "unknown," and "abnormal." "Normal" has a higher degree of certainty / reliability that the system call sequence is normal than "unknown." "Abnormal" has a higher degree of certainty / reliability that the system call sequence is abnormal than "unknown." In steps S36 to S37, the reflection unit 115 may set the monitoring level to low-frequency matching, high-frequency matching, or constant matching, depending on whether the judgment result of the judgment unit 114 is normal, unknown, or abnormal, respectively.

[0055] The reflection unit 115 may divide the load level of the monitoring device 100 into three stages, for example, high load, medium load, and low load, and determine the object of matching according to this stage. The reflection unit 115 may set the application function unit 111, which is a constant matching unit, as the target of matching if the load is high, may set the application function unit 111 to be a constant matching unit if the load is medium, and may set all the application function units to be a matching unit if the load is low.

[0056] The determination unit 114 may also change the frequency of determination depending on the monitoring level. In the above-described embodiment, the determination period is a period of a predetermined length that begins at a predetermined timing. The determination period may be shorter or the interval between determination periods may be longer for the application function unit 111 that performs low-frequency matching compared to high-frequency matching. The determination result levels and monitoring levels of the determination model 122 described so far are three-stage, but they may also be divided into more detailed levels. The lower the monitoring level, the shorter the matching period and determination period.

[0057] <<Variation: Changing the Monitoring Level>> In the above embodiment, the monitoring level (see FIG. 4) may change from on-demand matching to constant matching depending on the determination result of the determination unit 114, but there is no case in which constant matching changes to on-demand matching. If the determination result by the comparison unit 113 of the system call sequence called by the application function unit 111 that is set to constant matching continues for a predetermined period of time, the monitoring level may be changed to on-demand matching. In this way, the application function unit 111 that was set to constant matching due to an erroneous determination by the determination unit 114 changes to on-demand matching, thereby reducing the load on the matching process.

[0058] Furthermore, in the above-described embodiment, the monitoring level changes from occasional checking to constant checking depending on the determination result of the determination unit 114. When the application function unit 111 changes to constant checking, other application function units 111 that provide the same network service may also change to constant checking. Furthermore, other application function units 111 that provide the same network service and operate on other monitoring devices 100 may also change to constant checking. In this way, if one application function unit 111 is subjected to a cyber-attack, the monitoring level of the other application function units 111 that provide the same network service can be increased, enabling the threat to be dealt with quickly.

[0059] <<Variation: On-demand Matching>> In the above-described embodiment, a system call sequence called by the application function unit 111 whose monitoring level is on-demand matching is matched against the anomaly list 150 when the load on the monitoring device 100 is low. Alternatively, the system call sequence may not be matched even when the load on the monitoring device 100 is low. The determination unit 114 may determine that the system call sequence is abnormal, so that the monitoring level becomes constant matching and the system call sequence is matched against the anomaly list 150. In other words, the application function unit 111 is not initially a target for matching, but once it is determined to be abnormal, it becomes a target for matching.

[0060] <<Modification: Matching Target Change Processing>> In the matching target change processing (see FIG. 7) in the above-described embodiment, the reflection unit 115 changes the matching target (see FIG. 4) depending on the load on the monitoring device 100. The matching target may also be changed depending on the state / condition of another monitoring device 100. For example, when the application function unit 111 provides a network service, the reflection unit 115 may set all matching targets in the monitoring information database 160 (see FIG. 4) to "YES" when the arrival rate of service requests falls below a predetermined value (see step S42).

[0061] <<Modification: Determination Model>> In the above-described embodiment, the determination unit 114 determines normality / abnormality using one determination model 122. The determination unit 114 may make a determination using a determination model 122 corresponding to the application function unit 111.

[0062] <<Modification: Determination Unit>> In the above-described embodiment, the determination unit 114 determines whether a system call sequence is normal or abnormal using the determination model 122, which is a machine learning model, but other techniques may also be used. For example, a system call sequence may be deemed abnormal if it contains a system call other than a system call that is deemed safe. Furthermore, a system call sequence may be determined to be abnormal if it is successfully matched with a system call sequence that is shorter than the system call sequence in the anomaly list 150. Alternatively, the determination unit 114 may use a method that has lower processing costs than the matching process of the matching unit 113 and a lower probability of overlooking an abnormal system call sequence.

[0063] <<Modification: Monitoring System>> In the above-described embodiment, the collation unit 113 and the determination unit 114 operate on a computer on which the application function unit 111 operates. The computer on which the application function unit 111 and the acquisition unit 112 operate (monitored device) may be different from the computer on which the collation unit 113 and the determination unit 114 operate (monitoring device). For example, the monitoring device on which the collation unit 113 operates may use the determination model 122 to determine whether a system call sequence sent by multiple monitored devices is normal or abnormal. The same applies to the collation unit 113. In this way, it becomes possible for a single monitoring device to monitor application function units 111 operating on multiple monitored devices, which is expected to reduce monitoring costs.

[0064] <Other Modifications> Although several embodiments and modifications of the present invention have been described above, these embodiments are merely illustrative and do not limit the technical scope of the present invention. The present invention can take on various other embodiments, and various modifications such as omissions and substitutions can be made without departing from the spirit of the present invention. These embodiments and modifications are included within the scope and spirit of the invention described in this specification, etc., and are included in the invention described in the claims and their equivalents.

[0065] <Hardware Configuration> The monitoring device 100 according to the above-described embodiment is realized by a computer 900 having a configuration as shown in Fig. 8, for example. Fig. 8 is a hardware configuration diagram showing an example of the computer 900 that realizes the functions of the monitoring device 100 according to the above-described embodiment. The computer 900 includes a CPU 901, a ROM 902, a RAM 903, an SSD 904, an input / output interface 905 (referred to as an input / output I / F (Interface) in Fig. 8), a communication interface 906 (referred to as a communication I / F in Fig. 8), and a media interface 907 (referred to as a media I / F in Fig. 8). The computer 900 may include a hard disk drive (HDD) instead of the SSD 904, or may include an HDD in addition to the SSD 904.

[0066] The CPU 901 operates based on programs stored in the ROM 902 or the SSD 904, and performs control by the control unit 110 in Fig. 1. The ROM 902 stores a boot program executed by the CPU 901 when the computer 900 starts up, programs related to the hardware of the computer 900, and the like. The CPU 901 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display or printer, via an input / output interface 905. The CPU 901 acquires data from the input device 910 and outputs generated data to the output device 911 via the input / output interface 905.

[0067] The SSD 904 stores programs executed by the CPU 901 and data used by the programs. The communication interface 906 receives data from other devices (not shown) (e.g., a terminal using a network service provided by the application function unit 111) via a communication network and outputs the data to the CPU 901. It also transmits data generated by the CPU 901 to other devices via the communication network. The media interface 907 reads programs or data stored on a recording medium 912 and outputs the programs to the CPU 901 via the RAM 903. The CPU 901 loads the programs from the recording medium 912 onto the RAM 903 via the media interface 907 and executes the loaded programs. The recording medium 912 may be an optical recording medium such as a DVD (Digital Versatile Disk), a magneto-optical recording medium such as an MO (Magneto Optical Disk), a magnetic recording medium, a conductive memory tape medium, or a semiconductor memory.

[0068] For example, when the computer 900 functions as the monitoring device 100 according to the embodiment described above, the CPU 901 of the computer 900 executes the program 128 (see FIG. 1 ) loaded onto the RAM 903, thereby realizing the functions of the monitoring device 100. The CPU 901 reads and executes the program from the recording medium 912. Alternatively, the CPU 901 may read the program from another device via a communication network, or may install and execute the program 128 from the recording medium 912 onto the SSD 904.

[0069] <Effects> The effects of the device will be described below.

[0070] The monitoring device 100 according to the embodiment described above includes an acquisition unit 112 that, when a process (see application function unit 111) calls a system call that requests OS processing, acquires, as a comparison target list, a system call list that includes the called system call and system calls that the process has previously called.

[0071] The monitoring device 100 includes a storage unit 120 that stores an anomaly list 150 that indicates an anomaly system call list containing one or more system calls. The monitoring device 100 includes a comparison unit 113 that, when a process is a matching target process (see the matching targets in the monitoring information database 160 illustrated in FIG. 4 ), compares the matching target list called by the process with the system call list included in the anomaly list 150 to determine whether the matching target list is anomaly.

[0072] The monitoring device 100 includes a determination unit 114 that, when a process is not a matching target process, determines whether a matching target list called by the process is normal or abnormal using a predetermined determination model 122. The monitoring device 100 includes a reflection unit 115 that, when the determination unit 114 determines that the matching target list is abnormal, sets the process that called the matching target list as a matching target process.

[0073] According to the monitoring device 100, the list of system calls called by the process to be compared is compared with the anomaly list 150. Compared to comparing the lists of system calls called by all processes with the anomaly list 150, the processing cost of the comparison process can be reduced.

[0074] Furthermore, if the determination unit 114 determines that the system call list called by a process is abnormal, the reflection unit 115 sets that process as a target for comparison. The system call list called by a process that was normal when first started but later became suspect of being abnormal is compared with the abnormality list 150. While there is no possibility of an abnormality, the comparison process is not performed, thereby reducing the processing cost of the comparison process.

[0075] The processes according to the above-described embodiment (see the application function unit 111) include processes that are constantly compared and processes that are occasionally compared that are compared when a predetermined condition is met (see the monitoring level of the monitoring information database 160 in FIG. 4). If the load on the monitoring device 100 is equal to or less than a predetermined value, the reflection unit 115 determines that the predetermined condition is met and sets the processes that are occasionally compared together with the processes that are constantly compared as processes to be compared (see step S41→YES and step S42 in FIG. 7). If the load on the monitoring device 100 exceeds a predetermined value, the reflection unit 115 sets the processes that are constantly compared as processes to be compared (see step S41→NO and step S43 in FIG. 7).

[0076] With this monitoring device 100, it is possible to increase or decrease the number of processes to be compared depending on the load situation. When the load is low, it is possible to compare the system call lists called by many processes, thereby increasing the level of countermeasures against security threats. When the load is high, it is always limited to comparing the system call lists called by the processes to be compared against the anomaly list 150, thereby reducing the processing cost of the comparison process.

[0077] The acquisition unit 112 according to the embodiment creates a matching list (a sequence of system calls) that includes the order in which the processes invoked the system calls. The explanatory variables that serve as input to the determination model 122 are the matching list that includes the order.

[0078] With such a monitoring device 100, it is expected that the accuracy of the normal / abnormal determination by the determination unit 114 will be improved compared to when the determination is based on a group of system calls that does not take into account the order in which the system calls are called. Furthermore, the processing cost of the determination unit 113 can be reduced by comparing a list of system calls called by processes that are likely to be abnormal with the abnormality list 150.

[0079] The predetermined judgment model 122 according to the embodiment described above is a machine learning model in which the explanatory variable is a match target list, and which is generated using the match target list called by a process in a normal operating state as learning data.

[0080] The monitoring device 100 can determine whether the matching list is normal or abnormal by comparing it with processes that are operating normally. There is no need to create a list of abnormal system calls, and the determination model 122 can be generated without much effort.

[0081] REFERENCE SIGNS LIST 100 Monitoring device 111 Application function unit 112 Acquisition unit 113 Collation unit 114 Determination unit 115 Reflection unit 121 Monitoring log 122 Determination model 131 Application data 132 Application program 128 Program 140 Call history database 150 Abnormality list 160 Monitoring information database

Claims

1. A monitoring device comprising: an acquisition unit that, when a process invokes a system call that requires OS processing, acquires a system call list that combines the invoked system call and system calls that the process has invoked in the past as a comparison list; a storage unit that stores an abnormality list that indicates an abnormal system call list that includes one or more system calls; a comparison unit that, when the process is a comparison target process, compares the comparison target list called by the process with a system call list included in the abnormality list to determine whether the comparison target list is abnormal; a determination unit that, when the process is not a comparison target process, determines whether the comparison target list called by the process is normal or abnormal using a predetermined determination model; and a reflection unit that, when the determination unit determines that the comparison target list is abnormal, designates the process that invoked the comparison target list as the comparison target process.

2. The monitoring device according to claim 1, wherein the processes include processes to be constantly compared and processes to be occasionally compared that are compared when a predetermined condition is met, and the reflection unit determines that the predetermined condition is met if the load on the monitoring device is equal to or less than a predetermined value, and sets the processes to be compared together with the processes to be occasionally compared, and if the load on the monitoring device exceeds the predetermined value, sets the processes to be compared together with the processes to be compared.

3. The monitoring device according to claim 1, wherein the acquisition unit includes in the comparison target list the order in which the process invoked the system calls, and the explanatory variables that serve as input to the judgment model are the comparison target list that includes the order.

4. The monitoring device according to claim 1, wherein the predetermined judgment model is a machine learning model whose explanatory variables are the matching target list and which is generated using the matching target list called by the process in a normal operating state as learning data.

5. A program for causing a computer to function as the monitoring device according to any one of claims 1 to 4.

Images