WO2026004111A1 - Monitoring device and program - Google Patents

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

The present invention relates to a monitoring device and program that monitors system call invocations by applications.

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.

In virtual network infrastructure, the use of container technology is becoming more widespread, 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. For this reason, security that constantly monitors and detects suspicious behavior and anomalies and takes measures against threats is extremely important.

Applications, including containers, access the kernel using system calls to use memory and other shared resources. However, if all system calls used were permitted, the security of the entire system would 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.

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.

To address this issue, Non-Patent Document 1 proposes filtering that takes into account the order in which system calls are invoked (sequence pattern, system call sequence), instead of filtering individual system calls.

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.

Non-Patent Document 1 describes a method for extracting system call sequences that could pose a threat. Detecting system call sequences extracted from application system call invocations enables more accurate threat detection than setting permission/denial for each individual system call. However, the processing cost of constantly monitoring all applications is high, which poses a major practical problem.
The present invention has been made in view of the above background, and an object of the present invention is to enable efficient monitoring of multiple invocations of system calls.

In order to solve the above-mentioned problems, the monitoring device of the present invention comprises: an acquisition unit that, when a process invokes a system call that requests OS processing, acquires a system call list that combines the invoked system call and system calls previously invoked by the process as a comparison target list; a storage unit that stores an abnormality list that indicates an abnormal system call list containing one or more system calls; a comparison unit that, when the process is a comparison target process, compares the comparison target list invoked by the process with the system call list contained 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 invoked 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.

This invention makes it possible to efficiently monitor multiple system call invocations.

FIG. 2 is a functional block diagram of the monitoring device according to the embodiment. FIG. 2 is a data configuration diagram of a call history database according to the present embodiment. FIG. 4 is a data configuration diagram of an abnormality list according to the embodiment. FIG. 2 is a data configuration diagram of a monitoring information database according to the embodiment. FIG. 10 is a sequence diagram of a matching process according to the embodiment. FIG. 10 is a sequence diagram of a determination process according to the present embodiment. 10 is a flowchart of a process for changing a matching target according to the present embodiment. FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of the monitoring device according to the above-described embodiment.

<Overview of the monitoring device>
An overview of a 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 application that made the call. Note that hereinafter, an application is also referred to as an application process or simply as a process.

Not all processes are necessarily targets for matching the system call sequences they invoked against the anomaly list. For example, if the monitoring device determines that a process is normal, it will not include that process in the matching list if the load on the monitoring device is heavy. Machine learning technology, for example, is used to determine whether a process is normal.
Such a monitoring device can reduce the load of checking a system call sequence against an anomaly list, enabling efficient invocation monitoring of system calls.

<Configuration of monitoring device>
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.

≪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 storage contents of the storage unit 120 may be stored in an external storage device such as a cloud server and read as needed. The program 128 describes the processes executed by an acquisition unit 112, a collation unit 113, a judgment unit 114, and a reflection unit 115 included in the control unit 110 (described later).

<Storage unit: application data and application programs>
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 the 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.

<Storage unit: call history database>
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. In FIG. 2 and subsequent figures, "SC" stands for system call.

<Memory section: Abnormality list>
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, along with 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.

When the monitoring device 100 detects the invocation of a system call that is on the anomaly list 150, it executes a predetermined response process. The predetermined response process may include recording the system call in a monitoring log, returning an error without processing the call, or stopping the calling application. In the following, the predetermined response process will be defined as returning an error without processing (executing) the call, and recording it in the monitoring log (see monitoring log 121 described below).

Assume that an application (process) invokes system calls in the order of system call 3, system call 23, system call 15, and system call 64, as shown in the first list in Figure 3. 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.

<Memory section: monitoring information database>
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.

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 specified condition is met. An example of a specified condition is that the load on the monitoring device 100 is below a specified value.

The matching target indicates whether the system call sequence currently invoked by the application is being matched against the anomaly list 150 ("YES"/"NO"). In Figure 4, the specified condition is not met (for example, the load on the monitoring device 100 exceeds a specified value), so the "constant matching" application is not a matching target ("NO"). If the specified condition is met, all matching targets will be "YES", and the "constant matching" application will also be a matching target.

<<Storage section: monitoring log>>
1, the description of the storage unit 120 will be continued. 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 log includes identification information of the called application (e.g., process identification information), identification information of the call sequence, the time of the call, etc.

<Memory section: decision 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, a system call sequence that is considered to be different from the learned system call sequence can be determined to be abnormal.

<Monitoring device: control unit>
The control unit 110 includes 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 also 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.

<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. A system call is an instruction (function call) by which an application calls a function of the OS (kernel). The number of application function units 111 is not limited to one; generally, multiple application function units 111 are running.

<<Control unit: 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.

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

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

Next, we will explain the case where the application function unit 111 is not the target of comparison (see Figure 4) ("NO"). In this case, the acquisition unit 112 sends the system call sequence invoked 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 begins at a predetermined timing. For example, the determination period is a one-minute period every 10 minutes. The processing of the determination unit 114 will be described later.

<Control unit: Collation unit>
The collation unit 113 compares 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 returns 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).

For example, suppose the acquisition unit 112 sent system call 93, system call 3, system call 51, system call 63, and system call 43 (see the third call history in Figure 2). The last system call, 43, is the system call currently called by the application function unit 111. The subsequence, including the tail, of this system call sequence matches the third system call sequence in the anomaly list 150 (see Figure 3), and the comparison unit 113 determines that the comparison was successful. In this way, the comparison unit 113 compares whether the subsequence, including the tail, matches the system call sequence in the anomaly list 150.

<Control unit: 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 whether the system call sequence is normal or abnormal when the application function unit 111 that called the system call sequence is not the target of matching (see FIG. 4 ).

<Control section: Reflection section>
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.

Furthermore, if the load on the monitoring device 100 is below a predetermined value, the reflection unit 115 sets "YES" to all matching targets in the monitoring information database 160 (see Figure 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."

<<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 invoked 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 invokes a system call. Note that the process (determination process) related to a system call invoked 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."

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.

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.

In step S<b>15 , the collation unit 113 collates the received system call sequence with the system call sequences in the anomaly list 150 .
In step S<b>16 , the matching unit 113 sends the matching result to the acquisition unit 112 .
In step S17, if the collation result is successful (step S17 → success), the acquisition unit 112 proceeds to step S18, and if the collation result is unsuccessful (step S17 → failure), the acquisition unit 112 proceeds to step S20.

In step S18, the acquisition unit 112 records the current time, process identification information, system call 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 to the application function unit 111 by using, for example, a function of the OS (kernel) of the monitoring apparatus 100.

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 made in step S20 to the application function unit 111 using, for example, a function of the OS (kernel) of the monitoring apparatus 100.

<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."

Steps S31 to S33 are the same processes 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.

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 (see FIG. 4) of the application function unit 111 to "constant collation" and the collation target to "YES."
Steps S38 and S39 are the same processes as steps S20 and S21 (see FIG. 5).

<<Comparison target change process>>
7 is a flowchart of the process of changing the matching target according to this embodiment. The process of changing the matching target is executed at a predetermined timing, for example, periodically.

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 exceeds the predetermined value (step S41 → NO), the reflection unit 115 proceeds to step S43.

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

<Features of the monitoring device>
The monitoring device 100 monitors the invocation of a system call 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 invocation of the system call by failing the invocation (see step S19).

When the load is low, the monitoring device 100 compares the system call sequences invoked for all application function units 111 in the monitoring information database 160 (see Figure 4) against the anomaly list 150. When the load is high, the monitoring device 100 compares the system call sequences invoked for application function units 111 with a monitoring level of "constant comparison" against the anomaly list 150. In this way, by expanding or reducing the scope of comparison depending on the load on the monitoring device 100, efficient monitoring of system call invocations becomes possible.

Furthermore, when the monitoring device 100 determines that the system call sequence called by the application function unit 111 is abnormal, it causes the comparison unit 113 to compare the system call sequence 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 operation, it compares it with the anomaly list 150, thereby monitoring the application function unit 111 with a more accurate method.

<<Variation: 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.

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 the set of system calls called by the application as explanatory variables. The determination unit 114 may use such a determination unit 114 to determine normality/abnormality.

<<Variation: Number of Monitoring Levels>>
In the above embodiment, there are two monitoring levels: "constant matching" and "occasional matching." This is not limiting, and three or more monitoring levels may be used. For example, the judgment results of the judgment model 122 may 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.

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. If the load is high, the reflection unit 115 may select the application function unit 111, which is a constant matching unit, as the object of matching; if the load is medium, the reflection unit 115 may select constant matching and high-frequency matching; and if the load is low, the reflection unit 115 may select all the objects of matching.

The determination unit 114 may also change the frequency of determination depending on the monitoring level. In the above 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 may be further divided into finer levels. The lower the monitoring level, the shorter the matching period and determination period.

<<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 will be changed to on-demand matching, thereby reducing the load on the matching process.

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

<<Variation: On-demand collation>>
In the above-described embodiment, a system call sequence called by the application function unit 111 whose monitoring level is "constant check" is checked against the anomaly list 150 when the load on the monitoring device 100 is low. Alternatively, the system call sequence may not be checked 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 check" and the system call sequence is checked against the anomaly list 150. In other words, the application function unit 111 is not initially a target for checking, but once it is determined to be abnormal, it becomes a target for checking.

<<Modification: Matching Target Change Process>>
In the matching target change process (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" if the arrival rate of service requests falls below a predetermined value (see step S42).

<<Variation: Judgment Model>>
In the above embodiment, the determination unit 114 determines whether the function is normal or abnormal using one determination model 122. The determination unit 114 may also determine whether the function is normal or abnormal using a determination model 122 corresponding to the application function unit 111.

<Modification: Determination Unit>
In the above 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. Alternatively, a system call sequence may be deemed 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.

<<Variation: Surveillance System>>
In the above-described embodiment, the collation unit 113 and the determination unit 114 operate on the 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.

Other variations
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.

<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 a HDD in addition to the SSD 904.

The CPU 901 operates based on a program 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 is started 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 via the input/output interface 905, and outputs generated data to the output device 911.

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) (for example, a terminal that uses a network service provided by the application function unit 111) via a communication network and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.
The media interface 907 reads a program or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads the program from the recording medium 912 onto the RAM 903 via the media interface 907 and executes the loaded program. The recording medium 912 is 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, a semiconductor memory, or the like.

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 the program from the recording medium 912 and executes it. Alternatively, the CPU 901 may read the program from another device via a communications network, or may install the program 128 from the recording medium 912 onto the SSD 904 and execute it.

Effect
The effects of the device will be explained below.

The monitoring device 100 according to the embodiment described above includes an acquisition unit 112 that, when a process (see application function unit 111) invokes a system call that requests OS processing, acquires, as a comparison list, a system call list that combines the invoked system call and system calls previously invoked by the process.

The monitoring device 100 includes a storage unit 120 that stores an abnormality list 150 that indicates a list of abnormal system calls that include one or more system calls.
The monitoring device 100 includes a comparison unit 113 that, when a process is a comparison target process (see the comparison targets in the monitoring information database 160 shown in Figure 4), compares the comparison target list called by the process with the system call list included in the abnormality list 150 to determine whether the comparison target list is abnormal.

The monitoring device 100 includes a determination unit 114 that, when a process is not a process to be compared, determines whether a list to be compared called by the process is normal or abnormal using a predetermined determination model 122 .
The monitoring apparatus 100 includes a reflection unit 115 that, when the determination unit 114 determines that the comparison target list is abnormal, sets the process that called the comparison target list as the comparison target process.

With this monitoring device 100, the list of system calls called by the process being compared is compared with the anomaly list 150. This reduces the processing cost of the comparison process compared to when the lists of system calls called by all processes are compared with the anomaly list 150.

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

The processes in the above-described embodiment (see application function unit 111) include processes that are always subject to matching and processes that are subject to matching whenever certain conditions are met (see the monitoring level of the monitoring information database 160 in Figure 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 process to be checked at any time as well as the process to be checked at all times as a process to be checked (see step S41 → YES and step S42 in FIG. 7).
If the load on the monitoring apparatus 100 exceeds a predetermined value, the reflection unit 115 always sets the process to be checked as the process to be checked (see step S41→NO and step S43 in FIG. 7).

With this type of 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 costs of the comparison process.

The acquisition unit 112 according to the embodiment creates the matching list (system call sequence) including the order in which the process invoked the system calls.
The explanatory variables that are input to the determination model 122 are a list of matching targets that includes an order.

Using this monitoring device 100, it is expected that the accuracy of the judgment unit 114's normal/abnormal judgment will be improved compared to when it is based on a group of system calls that does not take into account the order in which the system calls are called. Furthermore, by comparing the list of system calls called by processes that are likely to be abnormal with the abnormality list 150, the processing costs of the comparison unit 113 can be reduced.

The predetermined judgment model 122 according to the embodiment described above is a machine learning model whose explanatory variables are match target lists, and which is generated using match target lists called by processes in a normal operating state as learning data.

Using this monitoring device 100, it becomes possible to determine whether a 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.

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 (5)

an acquisition unit that, when a process invokes a system call that requests processing by an OS, acquires a system call list that includes the invoked system call and system calls that the process has invoked in the past as a list to be compared;
a storage unit configured to store an abnormality list indicating a list of abnormal system calls, the abnormal system calls including 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 process to be compared, determines whether the list of processes to be compared called by the process is normal or abnormal using a predetermined determination model;
a reflection unit that, when the determination unit determines that the comparison target list is abnormal, sets a process that has called the comparison target list as the comparison target process. The process includes:
There are processes that are always subject to matching and processes that are occasionally subject to matching when a predetermined condition is met.
The reflection unit
If the load of the monitoring device is equal to or less than a predetermined value, it is determined that the predetermined condition is satisfied, and the occasional comparison process is set as the comparison target process together with the constant comparison target process;
The monitoring device according to claim 1 , wherein if the load of the monitoring device exceeds the predetermined value, the process to be constantly compared is set as the process to be compared. The acquisition unit
The list to be checked includes the order in which the process invoked the system calls,
The explanatory variables that are input to the determination model are:
The monitoring device according to claim 1 , wherein the list of objects to be checked includes the order. The predetermined judgment model is
The monitoring device according to claim 1 , wherein an explanatory variable is the match target list, and the machine learning model is generated using the match target list called by the process in a normal operating state as learning data. A program for causing a computer to function as the monitoring device described in any one of claims 1 to 4.