Monitoring device and program

Abstract

This monitoring device (100D) refers to a transition risk level database (150) in which a risk level and a system call sequence including system calls equal to or less than a transition sequence length are stored. The monitoring device (100D) comprises a monitoring unit (113) that detects a call of a called system call. The monitoring device (100D) calculates a transition risk level by referring to the transition risk level database (150) on the basis of the called system call and a system call called prior to the called system call, and adds the transition risk level to a cumulative risk level at the time of the last call. The monitoring unit (113) executes a prescribed response process if the cumulative risk level is equal to or greater than a cumulative risk level threshold value.

Description

Monitoring Apparatus and Program

[0001] The present invention relates to a monitoring apparatus and a program for monitoring application system call invocations.

[0002] In recent years, virtual network infrastructures that build a network system on a general-purpose server using virtualization technology have become widespread. Introducing a virtual network infrastructure eliminates the need for communication carriers to procure dedicated hardware, and enables flexible allocation, movement, and deletion of resources through software control. Accordingly, significant cost reduction can be achieved.

[0003] In virtual network infrastructures, utilization of container technology has become widespread particularly in terms of cost and operational flexibility. When container technology is used, containers owned by multiple tenants share an OS and access common resources. For this reason, it is extremely important to constantly monitor and detect suspicious behavior and abnormalities, and implement countermeasures against threats.

[0004] Applications including containers access the kernel using system calls to use memory and other shared resources. Non-Patent Literature 1 proposes filtering that takes into account the calling order of system calls (sequence pattern, system call sequence).

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

[0006] Non-patent document 1 describes a method for extracting threatening system call sequences. However, Non-patent document 1 does not describe a method for detecting or disallowing threatening system call sequences in a real system, specifically for applications including containers. Even if threatening system call sequences are detected, the high overhead is likely to be a problem. This invention was made in view of this background, and aims to enable efficient monitoring of multiple system call invocations.

[0007] To solve the aforementioned problems, the monitoring device according to the present invention includes: a reference unit that refers to a transition risk database in which a system call sequence including two or more system calls to be monitored and less than or equal to the transition sequence length is associated with a risk degree indicating the security threat level of the system call sequence; a monitoring unit that detects an invocation system call, which is a system call that requests an OS service; a comparison unit that obtains the risk degree of a previously invocation system call sequence, which is a system call sequence consisting of the invocation system call notified by the monitoring unit and a past invocation system call, which is a system call that was invocation before the invocation system call, by referring to the transition risk database and uses it as the transition risk degree; adds the transition risk degree to the cumulative risk degree calculated at the time of the previous system call invocation to calculate the cumulative risk degree of the invocation system call; and determines whether the cumulative risk degree is equal to or greater than the cumulative risk degree threshold; and if the comparison unit determines that the cumulative risk degree is equal to or greater than the cumulative risk degree threshold, the monitoring unit executes a predetermined corresponding process.

[0008] According to the present invention, it is possible to efficiently monitor multiple system calls.

[0009] This is a functional block diagram of the monitoring device according to the first embodiment. This is a data configuration diagram of the malicious sequence list according to the first embodiment. This is a data configuration diagram of the transition risk database according to the first embodiment. This is a data configuration diagram of the call history database according to the first embodiment. This is a diagram showing an example of a monitoring log according to the first embodiment. This is a diagram for explaining the calculation of the cumulative risk level according to the first embodiment. This is a diagram for explaining the calculation of the cumulative risk level according to the first embodiment. This is a sequence diagram of the monitoring process according to the first embodiment. This is a sequence diagram of the monitoring process according to the first embodiment. This is a functional block diagram of the monitoring device according to the second embodiment. This is a functional block diagram of the monitoring device according to the third embodiment. This is a functional block diagram of the monitoring device according to a modified example. This is a data configuration diagram of the call history database according to a modified example. This is a functional block diagram of the monitoring device according to a modified example. This is a functional block diagram of the monitoring device according to a modified example, which includes a reference unit. This is a functional block diagram of the monitoring device according to a modified example, which includes a reference unit. This is a functional block diagram of the monitoring device according to a modified example, which includes a reference unit. This is a hardware configuration diagram showing an example of a computer that implements the functions of the monitoring device according to the above-described embodiment.

[0010] ≪Overview of the Monitoring Device≫ The overview of the monitoring device in an embodiment for carrying out the present invention is described below. The monitoring device is also a server on which an application including a container runs and which provides network services. The monitoring device detects system calls made by the application. The monitoring device stores a transition risk database (see Figure 3 below) generated based on a malicious sequence, which is a series of system calls (system call sequence) that constitute a security threat. The transition risk database stores system call sequences shorter than the malicious sequence and the risk level (security threat level) of the system call sequence.

[0011] The monitoring device obtains the risk level of the system call sequence, which consists of the invoked system call and system calls invoked prior to it, by referring to the transition risk level database, and uses this as the transition risk level. The monitoring device adds the transition risk level to the cumulative risk level calculated at the time of the previous system call invocation to obtain the cumulative risk level for the current system call invocation.

[0012] When the cumulative risk level exceeds a predetermined value (cumulative risk threshold), the monitoring device considers the application that invoked the system call to be a security threat and executes a corresponding action. These actions may include, for example, returning an error to the system call, issuing a warning to the monitoring device administrator, or recording the incident in the monitoring log.

[0013] The length of system call sequences stored in the transition risk database is shorter than that of malicious sequences. Therefore, matching invoked system call sequences with system call sequences included in malicious sequences requires less processing cost, resulting in a lower monitoring load and more efficient monitoring.

[0014] ≪Configuration of the Monitoring Device≫ Figure 1 is a functional block diagram of the monitoring device 100 according to the first embodiment. The monitoring device 100 is a computer and comprises a control unit 110, a storage unit 120, and a communication unit 180. The communication unit 180 is equipped with a communication device and sends and receives data to and from terminals that use network services provided by applications running on the monitoring device 100 (see application function unit 111 described later). In other words, the monitoring device 100 is also a server that provides network services.

[0015] <<Monitoring Device: Storage Unit>> The storage unit 120 is composed of storage devices such as ROM (Read Only Memory), RAM (Random Access Memory), and SSD (Solid State Drive). The storage unit 120 stores application data 131, application programs 132, a malicious sequence list 140, a transition risk database 150, a call history database 160, a monitoring log 121, and a program 122. The program 122 includes descriptions of the processing of the risk calculation unit 112, the monitoring unit 113, and the verification unit 114, which will be described later.

[0016] <<Storage Unit: Application Data and Application Programs>> Application data 131 is data accessed by applications running on the monitoring device 100 (see application function unit 111 described later). Application program 132 is the program for that application. If multiple applications are running on the monitoring device 100, application data 131 and application program 132 exist for each application. Note that each application contained in the container may be considered an application function unit 111.

[0017] ≪Storage Unit: Malicious Sequence List≫ Figure 2 is a data configuration diagram of the malicious sequence list 140 according to the first embodiment. In Figures 2 and below, "SC" refers to a system call. The malicious sequence list 140 is a list of system call sequences that constitute a security threat among the sequence of system calls invoked by the application, and their identification information (identification number). A security threat refers to an attack or preliminary stage of an attack, such as disrupting the execution of the OS or application of the monitoring device 100 or data theft.

[0018] In the following, the system call sequence in the malicious sequence list 140 will also be referred to as a malicious sequence. The monitoring device 100 will not permit the calling of a malicious sequence. In other words, the malicious sequence list 140 is a sequence of system calls that are prohibited from being called.

[0019] The malicious sequence list 140 may assign a risk level to each system call sequence. The risk level indicates the level of security threat that would arise if the system calls shown in the system call sequence were invoked. For example, the risk level of a system call sequence that leads to command execution with administrator privileges on the monitoring device 100 is higher than the risk level of a system call sequence that leads to command execution with general user privileges.

[0020] <<Storage Unit: Transition Risk Database>> Figure 3 is a data configuration diagram of the transition risk database 150 according to the first embodiment. The transition risk database 150 is generated by the risk calculation unit 112, which will be described later, based on the malignant sequence list 140. The transition risk database 150 stores identification information (indicated as "#" in Figure 3), system call sequences, and the transition risk level of the system call sequence in association with each other.

[0021] The system call sequences included in the transition risk database 150 are subsequences of the system call sequences included in the malicious sequence list 140, with a length of 2 or more and less than or equal to the transition sequence length. Therefore, even if a call is made as shown in the system call sequences included in the transition risk database 150, it is not immediately considered a threat (the threat level is low), but it is considered to have the potential to be a threat. If a series of system call sequences from the transition risk database 150 are repeated, the system call sequence from the malicious sequence list 140 is assumed to have been called, and the monitoring device 100 executes corresponding processing for the last system call.

[0022] <<Storage Unit: Call History Database>> Figure 4 is a data configuration diagram of the call history database 160 according to the first embodiment. The call history database 160 records the call history of system calls for each application (process). In the first embodiment, the application is identified by process identification information (labeled "PID" in Figure 4).

[0023] The call history database 160 includes the cumulative risk level at the time the system call was invoked. The transition risk level is the risk level of a single system call sequence in the transition risk level database 150. In contrast, the cumulative risk level shows the cumulative risk level resulting from the invocation of the system call sequence in the call history. The matching unit 114, described later, calculates the cumulative risk level.

[0024] ≪Storage Unit: Monitoring Log≫ Returning to Figure 1, we will continue the explanation of the storage unit 120. The monitoring log 121 (see Figure 5 below) includes the identification information of the called application (e.g., process identification information), the call sequence, the time of the call, etc.

[0025] ≪Monitoring Device: Control Unit≫ The control unit 110 is configured to include a CPU (Central Processing Unit) and comprises an application function unit 111, a risk calculation unit 112, a monitoring unit 113, and a verification unit 114. 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 made by the application function unit 111 is the target of monitoring. A system call is an instruction (function call) that an application uses to call a function of the OS (kernel). Note that there is not necessarily only one application function unit 111; generally, multiple application function units 111 are in operation.

[0026] ≪Control Unit: Risk Calculation Unit≫ The risk calculation unit 112 calculates the transition risk of the system call sequence, which is a subsequence of the malicious sequence, based on the malicious sequence, and generates a transition risk database 150 (see Figure 3). The risk calculation unit 112 ensures that the system call sequence is less than or equal to the transition sequence length. For example, the risk calculation unit 112 may divide the malicious sequence into subsequences of length 2, and the transition risk of the subsequence may be a value obtained by dividing a predetermined risk by the number of subsequences and adding a predetermined value. The predetermined risk may be, for example, the cumulative risk threshold described later, or if a risk is assigned to the malicious sequence, that risk may be used. It is desirable that the transition sequence length be shorter than the length of the malicious sequence.

[0027] The risk calculation unit 112 calculates the transition risk degree so that the same subsequence included in multiple malignant sequences has the same transition risk degree. The risk calculation unit 112 also calculates the transition risk degree so that the sum of the transition risk degrees of the subsequences obtained by dividing a malignant sequence that has been shortened by a predetermined length from the end is equal to or greater than the cumulative risk threshold described later.

[0028] For example, suppose system call 1, system call 2, system call 3, system call 5, and system call 6 are a malicious sequence (see Figure 2), and the predetermined shortened length is 1. Then, the sum of the transition risk levels of system call 1 and system call 2, system call 2 and system call 3, and system call 3 and system call 5 will be greater than or equal to the cumulative risk threshold. In other words, the sum of the transition risk levels will be greater than or equal to the cumulative risk threshold before the last system call of the malicious sequence is invoked.

[0029] ≪Control Unit: Monitoring Unit≫ The monitoring unit 113 monitors the system calls invoked by the application function unit 111. The monitoring unit 113 is called by, for example, the OS (kernel) of the monitoring device 100, and hooks (detects) and monitors the system calls invoked by the application function unit 111.

[0030] When the application function unit 111 invokes a system call, the monitoring unit 113 notifies the matching unit 114 of the identification information of the application function unit 111 (process) (process identification information) and the identification information of the invoked system call (invoking system call). The matching unit 114 then determines whether or not the invoking system call is a threat and returns the result.

[0031] If the system call is not deemed a threat, the monitoring unit 113 returns the call result to the application function unit 111. If the system call is deemed a threat, the monitoring unit 113 performs a predetermined response process. This response process may include returning an error to the system call, issuing a warning to the administrator of the monitoring device 100, or recording the result in the monitoring log 121. The monitoring unit 113 may also record the result in the monitoring log 121 while returning the call result to the application function unit 111.

[0032] The warning and monitoring log 121 may also include the ratio of the length of the matching system call sequence to the length of the malicious sequence for the malicious sequence that most closely matches the invoked system call sequence (the previously invoked system call sequence described below), which includes the invoked system call. Figure 5 shows an example of the monitoring log 121 according to the first embodiment. The monitoring log 121 records, for system call sequences determined to be threats, the time of detection, the process identification information of the invoking application, the system call sequence, and the matching ratio of the identification information of the malicious sequence that most closely matches the system call sequence.

[0033] ≪Control Unit: Verification Unit≫ Returning to Figure 1, we will continue the explanation of the control unit 110. The verification unit 114 stores the identification information of the calling system call notified by the monitoring unit 113 in the calling history database 160. Next, the verification unit 114 determines whether the calling system call is a threat or not and returns the result to the monitoring unit 113. The determination method will be explained below.

[0034] The matching unit 114 calculates the transition risk level resulting from the invocation of the system call by referring to the transition risk level database 150. For example, if the length of the system call sequence in the transition risk level database 150 is 2, the matching unit 114 compares this system call sequence with a system call sequence that includes the invocation system call and the system call immediately preceding it.

[0035] The system call sequence, which includes the incoming system call and the system call that was called before it (previously called system call), is referred to as the previously called system call sequence. If the length of the system call sequence in the transition risk database 150 is 3, the matching unit 114 compares the system call sequence with the previously called system call sequence of length 3 (the length of a previous called system call is 2). If the previously called system call sequence does not match any of the system call sequences in the transition risk database 150, the matching unit 114 sets the transition risk to 0.

[0036] Next, the matching unit 114 adds the transition risk level to the cumulative risk level of the system call prior to the call in the call history database 160. Subsequently, if the cumulative risk level is equal to or greater than the cumulative risk level threshold, the matching unit 114 determines that the system call is a threat.

[0037] Figure 6 is a diagram illustrating the calculation of the cumulative risk level according to the first embodiment. Assume that the application makes system call 1 (labeled "SC1" in Figure 6), system call 2, system call 3, and system call 4. Assume that the cumulative risk level before the call of system call 1 is 0. When system call 1 is called, followed by system call 2, the transition risk level is 10 (see Figure 3), and the cumulative risk level is 10. Next, when system call 3 is called, the transition risk level is 20, and the cumulative risk level is 30. Next, when system call 4 is called, the transition risk level is 30, and the cumulative risk level is 60. If the cumulative risk level threshold is 60, the call of system call 4 is determined to be a threat, and the monitoring unit 113 executes a corresponding process. For example, an error is returned in response to the call of system call 4.

[0038] The matching unit 114 reduces the cumulative risk level to a predetermined value if a predetermined number of system call invocations with a transition risk level of 0 occur consecutively. Figure 7 is a diagram illustrating the calculation of the cumulative risk level according to the first embodiment. The application calls system call 32, system call 33, system call 35, and system call 36, a sequence of system calls with a transition risk level of 0. If the predetermined number of invocations is 3 and the predetermined value is 10, the matching unit 114 reduces the cumulative risk level from 20 to 10 when system call 36 is called.

[0039] The matching unit 114 instructs the monitoring unit 113 to reduce monitoring if the cumulative risk level falls below the low risk threshold. Upon receiving this instruction, the monitoring unit 113 suspends notification to the matching unit 114 for a predetermined time after detecting a system call related to the application function unit 111 that invoked the calling system call. The monitoring unit 113 may also reduce the number of system call notifications (it may lower the notification frequency). For example, the monitoring unit 113 may notify the matching unit 114 of only one of ten calling system calls, and not the rest. Reducing monitoring is also referred to as lowering the monitoring level. If the suspension of notifications is considered to have a frequency of 0, the monitoring level can also be considered as the frequency at which the monitoring unit 113 notifies the matching unit 114 of the calling system call.

[0040] <Monitoring Process> Figures 8 and 9 are sequence diagrams of the monitoring process according to the first embodiment. When the application function unit 111 invokes a system call, the processes shown in Figures 8 and 9 are executed. In other words, the monitoring processes shown in Figures 8 and 9 are repeatedly executed each time the application function unit 111 invokes a system call.

[0041] In step S11, the application function unit 111 invokes a system call. This system call will be referred to as the invocation system call below. In step S12, the monitoring unit 113 detects the invocation of the invocation system call in step S11.

[0042] In step S13, if it is time to notify the system call invocation (step S13 → YES), the monitoring unit 113 proceeds to step S14. If there is no time to notify (step S13 → NO), the monitoring unit 113 ends the monitoring process. If monitoring is not sparse, it is time to notify. If monitoring is sparse and notification is currently interrupted, it is not time to notify. If monitoring is sparse and the notification frequency is not 1 (for each system call invocation), the timing for notification will depend on the frequency. For example, if the notification frequency is once every 10 invocations, then once every 10 invocations is the timing for notification.

[0043] In step S14, the monitoring unit 113 notifies the matching unit 114 of the identification information (process identification information) of the application function unit 111 that has called the invoked system call and the identification information of the invoked system call. In step S15, the matching unit 114 additionally registers the identification information of the invoked system call in the call history corresponding to the process identification information in the call history database 160.

[0044] In step S16, the matching unit 114 performs calculation by referencing the transition risk degree database 150 based on the invoked system call to acquire a transition risk degree. In step S17, the matching unit 114 updates the cumulative risk degree by adding the transition risk degree calculated in step S16 to the cumulative risk degree corresponding to the process identification information stored in the call history database 160.

[0045] In step S18, if the cumulative risk degree is equal to or higher than the cumulative risk degree threshold (step S18 → equal to or higher than the cumulative risk degree threshold), the matching unit 114 advances the processing to step S19. If the cumulative risk degree is less than the cumulative risk degree threshold (step S18 → less than the cumulative risk degree threshold), the matching unit 114 advances the processing to step S20.

[0046] In step S19, the monitoring unit 113 executes corresponding processing. In step S20, the monitoring unit 113 executes the invoked system call and returns the result to the application function unit 111.

[0047] Turning now to FIG. 9, the description of the monitoring processing will be continued. In step S21, if the transition risk degree has been 0 consecutively for a predetermined number of times (step S21 → YES), the matching unit 114 advances the processing to step S22. If the transition risk degree has not been 0 consecutively for the predetermined number of times (step S21 → NO), the matching unit 114 advances the processing to step S23.

[0048] In step S22, the matching unit 114 reduces the cumulative risk level. In step S23, if the cumulative risk level is equal to or lower than the low risk threshold (step S23 → equal to or lower than the low risk threshold), the matching unit 114 advances the process to step S24. If the cumulative risk level exceeds the low risk threshold (step S23 → exceeds the low risk threshold), the matching unit 114 ends the monitoring process for the called system call (see step S11).

[0049] In step S24, the matching unit 114 instructs the monitoring unit 113 to perform sparser monitoring. Upon receiving the instruction, the monitoring unit 113 performs sparser monitoring. For example, the monitoring unit 113 suspends the notification of system calls to the matching unit 114 for a predetermined period of time, or thins out the notifications of system calls.

[0050] <<Characteristics of the Monitoring Device>> The monitoring device 100 detects calls of system calls for each application function unit 111. The monitoring device 100 calculates a transition risk level and a cumulative risk level of the called system call to determine a threat of the called system call. If it is determined to be a threat, the monitoring device 100 performs a response process such as returning an error for the called system call. The calculation of the transition risk level is performed through matching with system call sequences whose length is equal to or less than a transition sequence length stored in a transition risk level database 150 (see FIG. 3), and has a smaller load than matching with a malignant sequence (see FIG. 2).

[0051] The monitoring device 100 reduces the cumulative risk level when calls of system calls having a transition risk level of 0 continue. When the cumulative risk level becomes equal to or lower than the low risk threshold, the monitoring device 100 performs sparser monitoring. When calls of system calls having a transition risk level of 0 continue, the load can be reduced by performing sparser monitoring on the application function unit 111 which can be regarded as having a low threat level.

[0052] The transition risk levels included in the transition risk database 150 are calculated so that the cumulative risk level reaches the cumulative risk level threshold before the system call sequence indicated in the malicious sequence is invoked (see risk calculation unit 112). As a result, the corresponding processing is executed before the malicious sequence is invoked. In other words, there is a risk that an attack may be achieved before the malicious instruction can be stopped if the system call sequence indicated in the malicious sequence is a perfect match, but this can be prevented.

[0053] <<Modification: Similar System Calls>> Some system calls are similar. For example, open and openat are similar system calls. Similar system calls may be treated as identical. For example, the matching unit 114 may treat a call to openat as a call to open and perform monitoring processing. In this case, all instances of openat in the transition risk database 150 and the malicious sequence list 140 are assumed to be open. By doing so, attacks using similar system calls can also be monitored.

[0054] ≪Second Embodiment≫ System calls that can be considered safe are predetermined, and the monitoring device may consider the transition risk level to be 0 when a calling system call can be considered safe. Figure 10 is a functional block diagram of the monitoring device 100A according to the second embodiment. Compared to the monitoring device 100 according to the first embodiment (see Figure 1), a safe system call list 145 is added to the storage unit 120, and the matching unit 114A is different.

[0055] The safe system call list 145 is a list of system calls that are considered safe and pose no threat. When calculating the transition risk level (see step S16 in Figure 8), the matching unit 114A first determines whether the calling system call is included in the safe system call list 145. If it is included, the matching unit 114A calculates that the transition risk level is 0.

[0056] With such a monitoring device 100A, if the call system call is safe, the transition risk level can be calculated without referring to the transition risk level database 150, thus streamlining the monitoring process.

[0057] ≪Third Embodiment≫ A risk level (threat level) can be set for each system call, and the monitoring device may change the calculation method for the transition risk level and the level of monitoring (system call notification) according to the risk level of the called system call. Figure 11 is a functional block diagram of the monitoring device 100B according to the third embodiment. Compared to the monitoring device 100 according to the first embodiment (see Figure 1), a system call risk level database 170 is added to the storage unit 120, and the monitoring unit 113B and the matching unit 114B are different.

[0058] The system call risk database 170 stores system calls associated with their risk levels (threat levels). During sparse monitoring (see step S24 in Figure 9), the monitoring unit 113B increases the monitoring level when it detects a system call with a high risk level (for example, a risk level equal to or greater than the high risk level of system calls). For example, if the notification of system calls to the matching unit 114B had been interrupted, the monitoring unit 113B resumes notification after the interruption. Also, if notifications had been reduced (the notification frequency had been lowered), the monitoring unit 113B increases the notification frequency. For example, the monitoring unit 113B increases the notification frequency from once every 10 calls to once every 5 calls. In this way, when the monitoring unit 113B detects a system call with a high risk level, it increases the monitoring level (system call notification frequency).

[0059] When calculating the transition risk level (see step S16 in Figure 8), the matching unit 114B first refers to the system call risk level database 170 to calculate the risk level of the invoked system call. If the risk level is low (for example, the risk level is less than or equal to the low risk level of the system call), it calculates the transition risk level according to the risk level, and if the risk level is high, it refers to the transition risk level database 150 to calculate the transition risk level. For example, suppose the risk level of the invoked system call is between 0 and 4. The matching unit 114B may calculate the transition risk level by referring to the transition risk level database 150 if the risk level is 0, if the risk level is 1, the transition risk level is 5, and if the risk level is 2 or higher, it calculates the transition risk level by referring to the transition risk level database 150.

[0060] Furthermore, the matching unit 114B may change the conditions for reducing the cumulative risk level depending on the cumulative risk level. In the matching unit 114 according to the first embodiment, if a predetermined number of system call invocations with a transition risk level of 0 continue, the cumulative risk level is reduced to a predetermined value (see steps S21 and S22 in Figure 9). If the cumulative risk level is high, the predetermined number of invocations may be increased. For example, if the cumulative risk level is 50 or more, it may be 20 times, and if the cumulative risk level is 40 or more, it may be 15 times, and so on. The higher the cumulative risk level, the stricter the conditions for reducing the cumulative risk level may be.

[0061] <<Variation Example: Attack Progress>> The system call sequence (previously called system call sequence) called by the application function unit 111 may be compared with the malicious sequence list 140, and based on the degree of match, an alarm may be issued or recorded in the monitoring log 121.

[0062] Figure 12 is a functional block diagram of a modified monitoring device 100C. Compared to the monitoring device 100 according to the first embodiment (see Figure 1), the risk calculation unit 112, monitoring unit 113, and verification unit 114 are replaced with a previously called risk degree calculation unit 115 and a notification unit 116. Also, the storage unit 120 lacks the transition risk degree database 150, and the call history database 160C is different. The previously called risk degree calculation unit 115 and the notification unit 116 are collectively referred to as the detection means.

[0063] Figure 13 is a data configuration diagram of the call history database 160C according to a modified example. Compared to the call history database 160 in the first embodiment (see Figure 4), there is no column (attribute, field) for cumulative risk level.

[0064] The previously called risk calculation unit 115 calculates the risk level of a previously called system call sequence based on the length of sub-sequences common to (matching) the previously called system call sequence and the malicious sequence, or the ratio of the length of sub-sequences to the malicious sequence. The risk level can be considered as the progress of an attack based on the malicious sequence. The notification unit 116 outputs the risk level (degree of risk) and the malicious sequence (corresponding attack method) that forms the basis for calculating the risk level if the risk level of the previously called system call sequence is equal to or greater than a predetermined value (predetermined risk level). Output methods include issuing an alarm, displaying it on a screen, or recording it in the monitoring log 121.

[0065] <Modification: Memory Unit> In the first embodiment described above, the monitoring device 100 stores application data 131, a malicious sequence list 140, a transition risk database 150, a call history database 160, and a monitoring log 121 in the memory unit 120. This data may also be stored in an external device (see the data server 500 described later).

[0066] Figure 14 is a functional block diagram of a modified monitoring device 100D. Compared to the monitoring device 100 of the first embodiment (see Figure 1), the control unit 110 is equipped with a reference unit 117. Also, the storage unit 120 does not contain application data 131, malicious sequence list 140, transition risk database 150, call history database 160, or monitoring log 121. This data is stored in a data server 500 that can communicate with the monitoring device 100D.

[0067] The reference unit 117 monitors data access by the application function unit 111, the risk calculation unit 112, the monitoring unit 113, and the verification unit 114, and replaces access (reading and writing) to the storage unit 120 with access to the data server 500.

[0068] The same applies to the monitoring devices 100A, 100B, and 100C, which may also be equipped with a reference unit 117 (see Figures 15, 16, and 17 described later). The same also applies to access to the safe system call list 145 in the second embodiment, the system call risk database 170 in the third embodiment, and the call history database 160C in the modified example.

[0069] Figure 15 is a functional block diagram of a modified monitoring device 100E, which includes a reference unit 117, relating to a modification of monitoring device 100A. Figure 16 is a functional block diagram of a modified monitoring device 100F, which includes a reference unit 117, relating to a modification of monitoring device 100B. Figure 17 is a functional block diagram of a modified monitoring device 100G, which includes a reference unit 117, relating to a modification of monitoring device 100C.

[0070] <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. For example, monitoring devices 100, 100A, 100B, 100D, 100E, and 100F include a risk calculation unit 112. Monitoring devices 100, 100A, 100B, 100D, 100E, and 100F may also include a transition risk database 150 generated by another device, and do not necessarily need to include a risk calculation unit 112.

[0071] The reference unit 117 accesses data on the data server 500. Alternatively, the monitoring devices 100, 100A, 100B, 100C, and 100D themselves may be considered as the data server 500, and the reference unit 117 may be considered as accessing the storage unit 120.

[0072] The present invention can take on various other embodiments, and furthermore, various modifications such as omissions and substitutions can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention as described herein, and are also included in the scope of the invention and its equivalents as described in the claims.

[0073] ≪Hardware Configuration≫ The monitoring devices 100, 100A, 100B, 100C, 100D, 100E, 100F, and 100G according to the above embodiment are implemented by a computer 900 having a configuration such as that shown in Figure 15. Figure 15 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of the monitoring devices 100, 100A, 100B, 100C, 100D, 100E, 100F, and 100G according to the above embodiment. The computer 900 includes a CPU 901, a ROM 902, a RAM 903, an SSD 904, an input / output interface 905 (labeled as input / output I / F (Interface) in Figure 15), a communication interface 906 (labeled as communication I / F in Figure 15), and a media interface 907 (labeled as media I / F in Figure 15). Computer 900 may be equipped with an HDD (Hard Disk Drive) instead of the SSD 904, or it may be equipped with an HDD in addition to the SSD 904.

[0074] The CPU 901 operates based on programs stored in the ROM 902 or SSD 904 and is controlled by the control unit 110 in Figure 1. The ROM 902 stores boot programs executed by the CPU 901 when the computer 900 starts up, as well as programs related to the computer 900's hardware. The CPU 901 controls input devices 910 such as a mouse and keyboard, and output devices 911 such as a display and printer, via the 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.

[0075] The SSD 904 stores programs executed by the CPU 901 and data used by those programs. The communication interface 906 receives data from other devices (not shown) via the communication network (e.g., terminals using network services provided by the application function unit 111, data server 500, etc.) and outputs it 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 programs or data stored in the recording medium 912 and outputs it to the CPU 901 via the RAM 903. The CPU 901 loads programs from the recording medium 912 onto the RAM 903 via the media interface 907 and executes the loaded programs. 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, or a semiconductor memory.

[0076] For example, when computer 900 functions as monitoring devices 100, 100A, 100B, 100C, 100D, 100E, 100F, and 100G according to the above embodiment, the CPU 901 of computer 900 realizes the functions of monitoring devices 100, 100A, 100B, 100C, 100D, 100E, 100F, and 100G by executing a program 122 (see Figure 1) loaded onto RAM 903. 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 communication network, or it may install the program 122 from the recording medium 912 onto the SSD 904 and execute it.

[0077] <<Effects>> The effects of monitoring devices 100, 100A, 100B, 100C, 100D, 100E, 100F, and 100G are described below.

[0078] The monitoring device 100D according to the above embodiment includes a reference unit 117 that refers to a transition risk database 150 (see Figure 3) which stores a system call sequence containing two or more system calls with a transition sequence length less than or equal to the number of system calls to be monitored, and a risk degree indicating the security threat level of the system call sequence. The monitoring device 100D includes a monitoring unit 113 that detects the invocation of an invoking system call, which is a system call that requests a service from the OS. The monitoring device 100D includes a matching unit 114 that obtains the risk degree of a previously invoked system call sequence, which is a system call sequence consisting of the invoking system call notified by the monitoring unit 113 and past invoking system calls, which are system calls that were invoked before the invoking system call, by referring to the transition risk database 150 and uses it as the transition risk degree. The matching unit 114 adds the transition risk degree to the cumulative risk degree calculated at the time of the previous system call to calculate the cumulative risk degree of the invocation of the invoking system call (see step S17). The matching unit 114 determines whether the cumulative risk level is equal to or greater than the cumulative risk level threshold (see step S18). If the matching unit 114 determines that the cumulative risk level is equal to or greater than the cumulative risk level threshold, the monitoring unit 113 executes a predetermined corresponding process (see step S19).

[0079] According to this monitoring device 100D, the system call sequence of previously called calls is compared with the system call sequence stored in the transition risk database 150 to calculate the transition risk and determine the cumulative risk. If the cumulative risk is equal to or greater than the cumulative risk threshold, it is determined that a threat has occurred and a corresponding process is executed. The length of the system call sequence in the transition risk database 150 is less than or equal to the transition sequence length, which reduces the load on calculating the transition risk and, consequently, the load on the monitoring device 100D to monitor for threat occurrences. In other words, the monitoring process is made more efficient.

[0080] The matching unit 114 according to the above embodiment sets the transition risk level to 0 if the previously called system call sequence is not in the transition risk level database 150 (see step S16 in Figure 8). The matching unit 114 reduces the cumulative risk level if the system call sequence with a transition risk level of 0 is called a predetermined number of times (see steps S21 and S22 in Figure 9). When the cumulative risk level falls below the low risk level threshold, the monitoring unit 113 suspends notification of the called system call to the matching unit 114 for a predetermined time, or reduces the frequency of notification of the called system call to the matching unit 114 (see step S24).

[0081] With such a monitoring device 100D, if the cumulative risk level is below the cumulative risk level threshold, the monitoring level can be lowered and the load reduced by interrupting or reducing the notification frequency of the calling system call. By reducing the load of monitoring applications (application function unit 111) that have a low cumulative risk level and can be considered safe, the load on the monitoring device 100D can be reduced.

[0082] The reference unit 117 of the monitoring device 100F according to the above embodiment further references the system call risk level database 170, in which system calls and risk levels indicating security threat levels are stored in association. If the monitoring unit 113B detects a system call with a risk level of high or higher while it has suspended notifications of incoming system calls, it resumes notifying the matching unit 114B of the incoming system call. If the monitoring unit 113B detects a system call with a risk level of high or higher while it has reduced the notification frequency of incoming system calls, it increases the notification frequency.

[0083] With such a monitoring device 100F, while the load of monitoring system calls is reduced, if a system call with a risk level of 100% or higher is detected, the monitoring level is increased, thereby reducing the chances of missing a threat.

[0084] The monitoring device 100D according to the above embodiment designates a sequence of system calls that, when invoked, poses a security threat as a malicious sequence (see malicious sequence list 140). The transition risk database 150 is configured such that the sum of the transition risk levels of the system call sequences obtained by dividing a malicious sequence, shortened to a predetermined length, from the end is equal to or greater than the cumulative risk threshold.

[0085] According to such a monitoring device 100D, a response process is performed before the entire malicious sequence of system calls is invoked and the attack is completed. Therefore, it becomes possible to prevent attacks before they occur.

[0086] The reference unit 117 of the monitoring device 100E according to the above embodiment further references the safe system call list 145, which is a list of system calls that do not pose a security threat. The matching unit 114A calculates the transition risk level as 0 when the calling system call is included in the safe system call list 145.

[0087] With such a monitoring device 100E, if a calling system call does not pose a threat, the transition risk level is calculated without matching it with the system call sequence in the transition risk level database 150, thus reducing the load on the monitoring device.

[0088] The predetermined response process according to the above embodiment is a process that returns an error to the invocation of the invocation system call. Alternatively, the predetermined response process is a process that issues an alarm including the invocation system call and past invocation system calls. Another predetermined response process is a process that records the invocation of the invocation system call, along with past invocation system calls, in the monitoring log 121.

[0089] Such a monitoring device 100D can prevent threats from occurring by returning an error in response to system calls that are deemed to be threats. Furthermore, by recording system calls that are deemed to be threats, it becomes possible to analyze the threats.

[0090] The predetermined response process according to the above embodiment is a process of issuing an alarm that includes the ratio of the length of a sub-sequence common to the previously called system call sequence and the malicious sequence to the length of the malicious sequence, and the previously called system call sequence. Alternatively, the predetermined response process is a process of recording the ratio of the length of a sub-sequence common to the previously called system call sequence and the malicious sequence to the length of the malicious sequence, together with the previously called system call sequence, in the monitoring log 121.

[0091] Such a monitoring device 100D allows for the analysis of the progression of a threat by recording the degree of match between previously called system call sequences and malicious sequences.

[0092] The monitoring device 100G is characterized by using a detection means that detects security threats using a system call sequence to output (for example, display on a computer screen, etc.) the degree of security risk detected and information on the corresponding attack method.

[0093] Such a monitoring device 100G makes it possible to identify attack methods, inform system operators of the attack methods being used as the threat progresses, and prompt them to take appropriate action early.

[0094] 100, 100A, 100B, 100C, 100D, 100E, 100F, 100G Monitoring device 111 Application function unit 112 Risk calculation unit 113, 113B Monitoring unit 114, 114A, 114B Verification unit 115 Previous call risk calculation unit (detection means) 116 Notification unit (detection means) 117 Reference unit 121 Monitoring log 122 Program 131 Application data 132 Application program 140 Malicious sequence list 145 Safe system call list 150 Transition risk database 160, 160C Call history database 170 System call risk database

Claims

1. A monitoring device comprising: a reference unit that refers to a transition risk database in which a sequence of system calls, which includes two or more system calls to be monitored and whose transition sequence length is less than or equal to the sequence of system calls, is associated with a risk level indicating the security threat level of the sequence of system calls; a monitoring unit that detects an invocation system call, which is a system call that requests a service from the OS; a reference unit that obtains the risk level of a previously invocation system call sequence, which is a sequence of system calls that includes the invocation system call notified by the monitoring unit and a previously invocation system call, by referring to the transition risk database and sets it as the transition risk level; a reference unit that adds the transition risk level to the cumulative risk level calculated at the time of the previous system call to calculate the cumulative risk level of the invocation of the invocation system call; and a comparison unit that determines whether the cumulative risk level is equal to or greater than the cumulative risk level threshold, wherein if the comparison unit determines that the cumulative risk level is equal to or greater than the cumulative risk level threshold, the monitoring unit executes a predetermined corresponding process.

2. The monitoring device according to claim 1, wherein the matching unit sets the transition risk level to 0 when the previously called system call sequence is not in the transition risk level database, reduces the cumulative risk level when the system call sequence with a transition risk level of 0 is called a predetermined number of times, and when the cumulative risk level falls below a low risk level threshold, the monitoring unit suspends notification of the called system call to the matching unit for a predetermined time, or reduces the frequency of notification of the called system call to the matching unit.

3. The monitoring device according to claim 2, wherein the reference unit further refers to a system call risk level database in which system calls and risk levels indicating security threat levels are stored in association, and the monitoring unit, while the notification of the calling system call is suspended, detects a system call with a risk level of high or higher, and resumes notifying the matching unit of the calling system call, and while the notification frequency of the calling system call is reduced, detects a system call with a risk level of high or higher, and increases the notification frequency.

4. A monitoring device according to claim 1, wherein a sequence of system calls that, when invoked, poses a security threat is defined as a malicious sequence, and the transition risk database is configured such that the sum of the transition risk levels of the system call sequences obtained by dividing the malicious sequence into predetermined shortened lengths is equal to or greater than the cumulative risk threshold.

5. The monitoring device according to claim 1, wherein the reference unit further references a safe system call list, which is a list of system calls that do not pose a security threat, and the matching unit calculates the transition risk level as 0 when the calling system call is included in the safe system call list.

6. The monitoring device according to claim 1, wherein the predetermined response process is a process that returns an error to the call of the calling system call, a process that issues an alarm including the calling system call and the past calling system call, or a process that records the call of the calling system call together with the past calling system call in the monitoring log.

7. The monitoring device according to claim 4, wherein the predetermined corresponding process is a process of issuing an alarm including the ratio of the length of a subsequence common to the previously called system call sequence and the malicious sequence to the length of the malicious sequence, or a process of recording the ratio of the length of a subsequence common to the previously called system call sequence and the length of the malicious sequence to the length of the previously called system call sequence together with the previously called system call sequence in the monitoring log.

8. A monitoring device characterized by outputting the degree of security risk detected and information on the corresponding attack method, using a detection means that detects security threats using a system call sequence.

9. A program for causing a computer to function as a monitoring device according to any one of claims 1 to 8.

Images