Monitoring device, program, and monitoring method

Abstract

A monitoring device (100) is provided with a monitoring unit (112), a collation unit (113), and a storage unit (120) for storing a monitoring target list (140), which is the list of a system call group including one or more system calls as monitoring targets. When a system call is called, the monitoring unit (112) sends a called system call which is the system call, and a system call called in the past to the collation unit (113) as collation targets. The collation unit (113) collates the collation targets with the system call group included in the monitoring target list (140), and determines whether the collation targets are the monitoring targets.

Description

Monitoring device, program, and monitoring method

[0001] The present invention relates to a monitoring device, a program, and a monitoring method 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 used to launch attacks, depending on the combination.

[0006] Instead of filtering individual system calls, filtering that takes into account the invocation order of system calls (sequence pattern, system call sequence) has been proposed (Non-Patent Document 1).

[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 system call sequences that could pose a threat. However, Non-Patent Document 1 does not describe a method for detecting or disallowing system call sequences that pose a threat in a real system, with respect to system call sequences that are called by applications that include containers. The present invention has been made in light of this background, and aims to make it possible to monitor multiple system call invocations.

[0009] In order to solve the above-mentioned problems, the monitoring device of the present invention includes a monitoring unit that, when a system call requesting an OS service is called, compares the called system call with system calls that have been called in the past; a memory unit that stores a monitoring target list, which is a list of system calls that include one or more system calls to be monitored; and a comparison unit that compares the comparison target with the system calls included in the monitoring target list to determine whether the comparison target is a monitoring target.

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

[0011] FIG. 1 is a functional block diagram of a monitoring device according to a first embodiment. FIG. 2 is a data structure diagram of a monitoring target list according to the first embodiment. FIG. 3 is a data structure diagram of a call history database according to the first embodiment. FIG. 4 is a sequence diagram of monitoring processing according to the first embodiment. FIG. 5 is a sequence diagram of monitoring processing according to a modified example of the first embodiment. FIG. 6 is a functional block diagram of a monitoring device according to a second embodiment. FIG. 7 is a data structure diagram of a monitoring target list according to the second 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 embodiments.

[0012] <Overview of Monitoring Device> 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 the call sequence of a system call, including past calls, with a monitoring list, which is a list of call sequences of system calls that pose a threat. If the call sequence of a system call is on the monitoring list, the monitoring device does not allow the system call to be invoked.

[0013] This monitoring device allows the system call call sequence to be set as permitted or not permitted, which makes it possible to ensure safety while ensuring availability, compared to conventional techniques that set the permission or not of individual system calls.

[0014] Configuration of Monitoring Device Fig. 1 is a functional block diagram of a monitoring device 100 according to a first 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 is configured to include storage devices such as a ROM (Read Only Memory), a RAM (Random Access Memory), and an SSD (Solid State Drive). The storage unit 120 stores application data 131, an application program 132, a monitoring target list 140, a call history database 150, a monitoring log 121, and a program 122. 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 122 is a description of the processing of the monitoring unit 112 and the collating unit 113, which will be 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: Monitoring Target List> FIG. 2 is a data configuration diagram of the monitoring target list 140 according to the first embodiment. In FIG. 2 and subsequent figures, "SC" refers to a system call. The monitoring target list 140 is a list of system call sequences that could pose a threat among the sequences of system calls invoked by applications, along with their identification information (identification numbers). A threat refers to an attack or pre-attack that interferes with the execution of the OS of the monitoring device 100 or other applications, or data theft. The monitoring device 100 denies invocation of system calls listed in the monitoring target list 140. In other words, the monitoring target list 140 is a sequence of system call invocations that are not permitted.

[0018] 2, if an application (process) invokes system calls in the order of system call 3, system call 23, system call 15, and system call 64, the monitoring device 100 will disallow the invocation of the last system call, 64. The monitoring device 100 may issue an alert instead of disallowing the invocation.

[0019] <Storage Unit: Call History Database> Fig. 3 is a data configuration diagram of the call history database 150 according to the first embodiment. The call history database 150 records the call history of system calls for each application (process). In the first embodiment, applications are identified by process identification information (denoted as "PID" in Fig. 3). In the example of Fig. 3, the application with process identification information "23" invokes the system calls in the following order: system call 53, system call 64, system call 2, system call 75, and system call 93.

[0020] 1, the description of the storage unit 120 will be continued. The monitoring log 121 records logs related to call sequences in the monitoring target list 140 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.

[0021] <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, a monitoring unit 112, and a matching unit 113. 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. The sequence of system calls called by the application function unit 111 is the target of monitoring. 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.

[0022] <<Control Unit: Monitoring Unit>> The monitoring unit 112 monitors system calls made by the application function unit 111. The monitoring unit 112 operates by being called by, for example, the OS (kernel) of the monitoring device 100, and hooks (detects) and monitors system calls made by the application function unit 111.

[0023] When an application function unit 111 invokes a system call, the monitoring unit 112 records which system call was invoked for each application function unit 111 (process) in the call history database 150 (see FIG. 3). The monitoring unit 112 also sends the system call sequence (call history) in the call history database 150 to the collation unit 113, which will be described later. The collation unit 113 then sends back the result of collation with the monitoring target list 140. A successful collation result means that the call history (the sequence of invoked system calls) is included in the monitoring target list 140, and that the call is a potential threat.

[0024] If the comparison is successful, the monitoring 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 monitoring unit 112 determines that the invoked system call is permitted, and returns the call result 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 monitoring target list 140.

[0025] <<Control Unit: Collation Unit>> The collation unit 113 collates the system call sequence (call history) sent by the monitoring unit 112 with each of the system call sequences in the monitoring target list 140. The collation unit 113 returns to the monitoring unit 112 the collation result (success / failure) indicating whether or not a matching system call sequence is found.

[0026] For example, suppose the monitoring 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 FIG. 3). 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 monitoring target list 140 (see FIG. 2), and the collation unit 113 determines that they match. In this way, the collation unit 113 verifies whether the subsequence, including the tail, matches the system call sequence in the monitoring target list 140.

[0027] <<Monitoring Process>> Fig. 4 is a sequence diagram of the monitoring process according to the first embodiment. The process in Fig. 4 is executed each time the application function unit 111 invokes a system call. In Fig. 4 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."

[0028] 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 monitoring unit 112 (the monitoring 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.

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

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

[0031] In step S18, the monitoring unit 112 records the current time, process identification information, system call invocation history, etc. in the monitoring log 121. In step S19, the monitoring 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.

[0032] In step S20, the monitoring unit 112 invokes a system call. In step S21, the monitoring 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.

[0033] <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 monitoring target list 140 (see step S17 → success in FIG. 4 ), it fails the system call invocation (see step S19), thereby disallowing the invocation. Compared to conventional techniques that set permission / denial for individual system calls, such a monitoring device 100 can ensure safety while ensuring availability.

[0034] <<Variation: Record and Allow Call>> In the above embodiment, the monitoring device 100 prohibits the invocation of a system call (returns an error) (see step S19) when the call history is in the monitoring target list 140. The monitoring device 100 may instead permit the call without returning an error and record it in the monitoring log 121.

[0035] <<Variation: Partial Collation by Monitoring Unit>> In the embodiment described above, the collation unit 113 determines whether or not there is a call history in the monitoring target list 140. Part of this determination may be performed by the monitoring unit 112. For example, if the call history includes system call 3, system call 23, and system call 15, the collation unit 113 returns system call 64 (see the first system call in the monitoring target list 140). If the next system call to be invoked is system call 64, the monitoring unit 112 may return an error and disallow the call.

[0036] In other words, if there is a possibility that the next system call will match the system call sequence in the monitoring target list 130, the collation unit 113 returns this next system call to the monitoring unit 112. The monitoring unit 112 disallows the next system call if it matches the system call returned by the collation unit 113. Note that if there are multiple system calls that may match, the collation unit 113 returns these multiple system calls, and if there are no system calls, it returns no possibility (0 system calls).

[0037] <<Modification: Checking N Calls Together>> In the first embodiment described above, the invocation history of a system call is checked against the monitoring target list 140 every time a system call is called. A predetermined number N may be set, and checking may be performed every N calls. The monitoring process in this modification will be described below. The monitoring unit and checking unit in this modification will be referred to as monitoring unit 112A and checking unit 113A.

[0038] 5 and 6 are sequence diagrams of the monitoring process according to a modification of the first embodiment. In step S31, the application function unit 111 and the monitoring unit 112A start the process of repeating steps S32 to S36 N-1 times. Steps S32 to S34 are the same as steps S11 to S13 shown in FIG. 4. Steps S35 to S36 are the same as steps S20 to S21. Steps S37 to S42 are the same as steps S11 to S16. In step S43, the monitoring unit 112A clears the call history corresponding to the application function unit 111 in the call history database 150. Steps S44 to S48 are the same as steps S17 to S21.

[0039] In the comparison in step S41, the comparison unit 113A checks whether a system call sequence (call history) of length N includes a system call sequence in the monitoring target list 140. In this modification, the length of the call history in the call history database 150 may be, for example, twice the maximum length of the system call sequence in the monitoring target list 140. With the configuration of this modification, it is possible to reduce the processing cost of the monitoring process compared to the first embodiment.

[0040] Second Embodiment In the first embodiment, a comparison is made to see whether a sequence of system call invocations is in the monitoring target list 140. Instead of comparing sequences, a group of invoked system calls may be compared, ignoring the invocation order.

[0041] 7 is a functional block diagram of a monitoring device 100B according to the second embodiment. Compared to the monitoring device 100 of the first embodiment (see FIG. 1), the monitoring device 100B differs in a monitoring unit 112B, a collating unit 113B, and a monitoring target list 140B.

[0042] 8 is a data configuration diagram of the monitoring target list 140B according to the second embodiment. Compared to the monitoring target list 140 (see FIG. 2) according to the first embodiment, an unordered set of system calls is stored instead of the ordered sequence of system calls. In FIG. 8, the set of system calls sorted by system call number is stored.

[0043] When the monitoring unit 112B sends the sequence of system calls in the call history to the collation unit 113B (see step S14 in FIG. 4), it sorts the sequence by system call number before sending it. When performing collation (see step S15), the collation unit 113B ignores the order in which the system calls are called and determines whether the call history includes a group of system calls in the monitoring target list 140B. With the configuration of the second embodiment as described above, the processing cost of the monitoring process can be reduced compared to the first embodiment.

[0044] <Other Modifications> Although several embodiments 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 thereof are included in the scope and spirit of the invention described in this specification, etc., and are included in the scope of the invention described in the claims and their equivalents.

[0045] <Hardware Configuration> The monitoring devices 100 and 100B according to the above-described embodiments are realized by a computer 900 having a configuration as shown in FIG. 9 , for example. FIG. 9 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the monitoring devices 100 and 100B according to the above-described embodiments. 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. 9 ), a communication interface 906 (referred to as a communication I / F in FIG. 9 ), and a media interface 907 (referred to as a media I / F in FIG. 9 ). 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.

[0046] 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.

[0047] 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.

[0048] For example, when the computer 900 functions as the monitoring device 100, 100B according to the above-described embodiment, the CPU 901 of the computer 900 executes the program 122 (see FIG. 1 ) loaded onto the RAM 903, thereby realizing the functions of the monitoring device 100, 100B. 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 122 from the recording medium 912 onto the SSD 904.

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

[0050] The monitoring device 100B according to the embodiment described above includes a monitoring unit 112B that, when a system call requesting an OS service is invoked, compares the system call with previously invoked system calls. The monitoring device 100B also includes a storage unit 120 that stores a monitoring target list 140B (see FIG. 8 ), which is a list of system calls including one or more system calls to be monitored. The monitoring device 100B also includes a comparison unit 113B that compares the comparison target with the system calls included in the monitoring target list 140B and determines whether the comparison target is a monitoring target.

[0051] The monitoring device 100B described above can ensure safety while ensuring availability, compared to the conventional technology that sets permission / prohibition for individual system calls.

[0052] The monitoring target list 140 (see FIG. 2 ) according to the embodiment described above includes the system call group, including the invocation order of the system calls included in the system call group. The monitoring unit 112 uses the invocation order of the system calls as a matching target. The matching unit 113 matches the matching target with the system call group included in the monitoring target list 140, including whether the invocation order of the system calls matches, and determines whether the matching target is a monitoring target.

[0053] According to such a monitoring device 100, by comparing the invocation of a system call with the monitoring target list more strictly, it is possible to reduce the possibility of erroneously determining that the match is successful, thereby improving availability.

[0054] 100, 100B Monitoring device 111 Application function unit 112, 112A, 112B Monitoring unit 113, 113A, 113B Collation unit 131 Application data 132 Application program 121 Monitoring log 122 Program 140, 140B Monitoring target list 150 Call history database

Claims

1. A monitoring device comprising: a monitoring unit that, when a system call that requests an OS service is called, compares the system call with system calls that have been called in the past; a storage unit that stores a monitoring target list, which is a list of system calls that include one or more system calls that are to be monitored; and a comparison unit that compares the comparison target with the system calls included in the monitoring target list to determine whether the comparison target is a monitoring target.

2. The monitoring device according to claim 1, wherein the list of system calls to be monitored includes the system calls, including the order in which the system calls were called, and the monitoring unit uses the order in which the system calls were called as the object of comparison, and the comparison unit compares the object of comparison with the system calls included in the list of system calls, including whether the order in which the system calls were called matches, to determine whether the object of comparison is a monitoring object.

3. A program for causing a computer having a storage unit that stores a monitoring target list, which is a list of system calls including one or more system calls to be monitored, to function as the monitoring device according to claim 1 or 2.

4. A monitoring method in which a monitoring device has a memory unit that stores a monitoring target list, which is a list of system calls that include one or more system calls that request OS services and are to be monitored, performs the following steps: when a system call is called, compares the calling system call, which is the system call, with system calls that have been called in the past; and compares the comparison target with the system calls included in the monitoring target list to determine whether the comparison target is a monitoring target.

Images