Profiling device and program

Abstract

A profiling device (100, 100A, 100B, 100C) comprises: a system call collection unit (110) that collects and monitors system calls issued by a computer system (1); a profile creation unit (120) that checks, in chronological order, system call logs collected by the system call collection unit (110), associates the system call logs with identification information to be monitored, and creates a system call profile (200, 200A) on the basis of a list arranged in order of frequency; and an abnormality detection unit (140) that detects abnormalities by comparing the system call profile to be monitored and the system call logs obtained by monitoring by the system call collection unit (110).

Description

Profiling apparatus and program

[0001] The present invention relates to a profiling apparatus and a program.

[0002] In recent years, information and communication technology has played an important role in various businesses, and many companies have built and operated a wide variety of computer systems. On the other hand, cyber attacks against computer systems, such as targeted attacks, have become increasingly prevalent.

[0003] In order to minimize the risk of cyber attacks, it is essential to provide a computer system with only the minimum necessary functions and authorities (not to grant unnecessary functions and authorities), detect abnormalities occurring in the computer system at an early stage, and enable prompt countermeasures. Here, consideration is given to minimizing the risk of cyber attacks against a computer system provided with a Linux OS ("Linux" is a registered trademark).

[0004] As threat detection techniques based on system calls (Non-Patent Document 3), there are sequence-based detection methods (Non-Patent Document 1) and frequency-based detection methods (Non-Patent Document 2).

[0005] Non-Patent Document 1 describes a threat detection method based on n-grams (partial sequences of fixed length n) of a system call sequence (a sequence in which identification information of called system calls (e.g., system call names and system call numbers) is arranged in chronological order). In the method of Non-Patent Document 1, a profile is created in advance from system call sequences acquired in a normal (e.g., threat-free) environment, and if a sequence observed during system operation deviates from the profile, it is determined to be abnormal (e.g., a threat is present).

[0006] Here, the "profile" is information that defines the "normal state" of the system. For example, it is a list obtained by enumerating all n-grams that appear in a normal system call sequence. If an n-gram observed during system operation is not present in this list, it can be determined to be abnormal (e.g., a threat is present).

[0007] Non-patent document 2 describes a threat detection method based on the frequency of each system call invoked over a certain period in the past. In the method described in non-patent document 2, a profile is created in advance from a system call sequence acquired in a normal (e.g., threat-free) environment, and if a sequence observed during system operation deviates from that profile, it is determined to be abnormal (e.g., threat present).

[0008] The method described in Non-Patent Document 2 uses the frequency distribution of each system call obtained from a normal system call sequence as the profile. The number of calls for each system call within a certain period is treated as a numerical vector (e.g., a point in Euclidean space), and a large number of these samples (e.g., numerical vectors of frequency distributions over different periods) are collected and clustered using Global K-means. If the numerical vector observed during system operation does not belong to any cluster, it can be determined that there is an anomaly (e.g., a threat).

[0009] According to Non-Patent Document 3, threat detection methods based on system calls can be broadly classified into two types: (1) sequence-based detection methods and (2) frequency-based detection methods. The above (1) sequence-based detection method is an n-gram-based method and corresponds to the method described in Non-Patent Document 1. The above (2) frequency-based detection method corresponds to the method described in Non-Patent Document 2.

[0010] It should be noted that n-grams and frequency distributions are merely ways of representing data. In addition to listing the data and applying K-means, it is also possible to create profiles using other machine learning models, clustering methods, deep learning, Bloom filters, and more.

[0011] C. Warrender, S. Forrest, and B. Pearlmutter, “Detecting Intrusions Using System Calls: Alternative Data Models,” in 1999 IEEE Symposium on Security and Privacy (SP), 1999, pp. 133-145, doi: 10.1109 / SECPRI.1999.766910. M. -K. Yoon, S. Mohan, J. Choi, M. Christodorescu, and L. Sha, “Learning Execution Contexts from System Call Distribution for Anomaly Detection in Smart Embedded System,” in 2017 IEEE / ACM International Conference on Internet-of-Things Design and Implementation (IoTDI), 2017, pp. 191-196. M. Liu, Z. Xue, X. Xu, C. Zhong, and J. Chen, “Host-based Intrusion Detection System with System Calls: Review and Future Trends,” ACM Computing Surveys, vol. 51, no. 5, article 98, pp. 1-36, 2018, doi: 10.1145 / 3214304. eBPF - Introduction, Tutorials & Community Resources, Accessed: Dec. 4, 2023, [online], [Searched January 5, Reiwa 7], Internet <URL: https: / / ebpf.io / >

[0012] The method described in Non-Patent Document 1 detects threats based on system calls made in the most recent short period, while the method described in Non-Patent Document 2 detects threats based on the frequency distribution of system calls made over a longer period. The two detection methods in Non-Patent Document 1 and Non-Patent Document 2 can detect different types of threats (e.g., cyberattacks), and applying only one of them to a system may result in missing some threats. The problems with the methods in Non-Patent Document 1 and Non-Patent Document 2 will be described in detail below.

[0013] <Problems with the method in Non-Patent Document 1> The method in Non-Patent Document 1 ("sequence-based detection method") is a detection method that only considers features related to a short period (n (fixed-length) system calls), and therefore tends to overlook changes in frequency distribution over longer periods. As a result, it may not be able to accurately detect attacks that are executed using the same system call sequences as usual (for example, DoS (Denial of Service) attacks). Generally, a relatively small value such as 6-gram or 10-gram is adopted as n (if the value of n is made too large, the computational cost becomes enormous and the accuracy also decreases).

[0014] <Problems with the method in Non-Patent Literature 2> The method in Non-Patent Literature 2 ("frequency-based detection method") is a detection method that only considers features related to long periods (on the order of 100 to 1000 system calls), and therefore is prone to overlooking critical system calls that are called infrequently. As a result, it may not be able to accurately detect attacks (e.g., privilege escalation) that involve only a small number of system calls that are not frequently used under normal conditions.

[0015] In light of this background, the present invention aims to provide a profiling device and program that can detect threats more accurately by simultaneously considering the frequency distribution of most recently invoked system calls and system calls invoked over a longer period.

[0016] To solve the aforementioned problems, the present invention provides a profiling device using system call profiling, comprising: a system call collection unit that collects and monitors system calls issued by a target to be monitored; a profile creation unit that checks the system call logs collected by the system call collection unit in chronological order, links them with identification information of the target to be monitored, and creates a system call profile based on a list arranged in frequency order; and an anomaly detection unit that performs anomaly detection by comparing the system call profile of the target to be monitored with the system call logs obtained by the system call collection unit through monitoring.

[0017] According to the present invention, by simultaneously considering the frequency distribution of most recently invoked system calls and system calls invoked over a longer period, it is possible to detect threats with greater accuracy.

[0018] This is a configuration diagram showing a profiling device according to the first embodiment of the present invention. This is a diagram showing a system call profile created by the profile creation unit of the profiling device according to the first embodiment of the present invention. This is a flowchart showing the operation of anomaly detection unit of the profiling device according to the first embodiment of the present invention. This is a configuration diagram showing a profiling device according to the second embodiment of the present invention. This is a diagram showing a system call profile created by the profile creation unit of the profiling device according to the second embodiment of the present invention. This is a flowchart showing the operation of the anomaly detection unit of the profiling device according to the second embodiment of the present invention. This is a configuration diagram showing a profiling device according to the third embodiment of the present invention. This is a configuration diagram showing a profiling device according to the fourth embodiment of the present invention. This is a hardware configuration diagram showing an example of a computer that realizes the functions of a profiling device according to an embodiment of the present invention.

[0019] The following describes a profiling device and the like in an embodiment of the present invention (hereinafter referred to as "this embodiment") with reference to the drawings. (First Embodiment) In the first embodiment, a system call profile is created for the monitored target (the entire computer system or a specific computer that constitutes it, or a specific process or application that runs on it, etc.), and anomaly detection is performed based on it. [Overall Configuration] Figure 1 is a configuration diagram showing a profiling device 100 according to the first embodiment of the present invention. As shown in Figure 1, the profiling device 100 detects anomalies in the computer system 1 based on the profiling of the system calls of the monitored computer system 1.

[0020] [Computer System 1] Computer System 1 is a system composed of one or more Linux computers. Here, a Linux computer is a computer equipped with the Linux OS (Operating System), and includes PCs, physical servers, mobile information terminals such as smartphones and tablets, virtual machines, containers, etc. However, this also applies to Computer System 1 composed of computers equipped with operating systems other than Linux, as long as they issue system calls or similar functions. Computer System 1 may be connected to an external network such as the Internet.

[0021] [Profiling device 100] The profiling device 100 comprises a system call collection unit 110, a profile creation unit 120, a profile database 130 (profile storage unit), and an anomaly detection unit 140.

[0022] The profiling device 100 is configured, for example, by a server. When the profiling device 100 is configured by a server, each functional unit is composed of a CPU (Central Processing Unit) or the like on hardware. In addition to the CPU, it can also be a processor such as a GPU (Graphic Processing Unit), FPGA (Field Programmable Gate Array), or ASIC (Application Specific Integrated Circuit). The profiling device 100 detects anomalies based on the profiling of system calls.

[0023] The profiling device 100 has the following two phases: a "profile creation phase" in which the profiling device 100 collects system calls issued by the monitored system for a certain period of time in advance and creates a profile, and a "profile application phase" in which the created profile is applied to the monitored system to perform anomaly detection.

[0024] The "profile creation phase" is performed by the profile creation unit 120 (described later), and the "profile application phase" is performed by the anomaly detection unit 140 (described later).

[0025] Furthermore, the "profile creation phase" executed by the profile creation unit 120 and the "profile application phase" executed by the anomaly detection unit 140 are asynchronous. For this reason, the system call list creation in the "profile creation phase" is performed by the profile creation unit 120 in advance of the anomaly detection unit 140's profile monitoring (anomaly detection), and the system call list to be referenced is stored in advance.

[0026] In the "Profile Creation Phase," it is assumed that no attacks will occur. If the system call characteristics change due to updates to the monitored system or specification changes, the "Profile Creation Phase" is returned to update the profile.

[0027] <System Call Collection Unit 110> The system call collection unit 110 collects and monitors system calls issued by the monitored target (computer system 1). Specifically, the system call collection unit 110 collects and records the identification information of issued system calls (e.g., system call name and system call number) in chronological order. If the monitored target is narrowed to a specific computer, process, or application rather than the entire computer system 1, it is necessary to also record their identification information (e.g., host name / host ID, process name / process ID, application name / application ID). Other additional information (e.g., issuance time, arguments, return value) may also be recorded.

[0028] Monitoring and collecting such system calls can be achieved, for example, by using the extended Berkley Packet Filter (eBPF) (Non-Patent Document 4).

[0029] The system call collection unit 110 inputs the collected and recorded system call logs (system call logs (records)) into the profile creation unit 120 and the anomaly detection unit 140.

[0030] The method for inputting system call logs into other functional units may be determined arbitrarily by the implementer of the present invention in accordance with security requirements, performance requirements, etc. Methods for inputting system call logs include sequential input immediately after each system call is collected, buffering a certain amount of system calls before inputting, buffering a certain number of system calls before inputting, and buffering a certain amount of system calls for a certain period of time or a certain number of times for each identification information related to a process or user before inputting.

[0031] There are well over 300 types of system calls, and attempting to monitor and collect all of them could place a significant load on the system. Therefore, it may be acceptable to collect and record only a selection of system calls that are useful for security monitoring and anomaly detection.

[0032] <Profile Creation Unit 120> In the "Profile Creation Phase," the profile creation unit 120 checks the system call logs collected by the system call collection unit 110 in chronological order, links them to the identification information of the monitored target, and creates a system call profile based on the resulting list (system call list LFU List) arranged in frequency order. For the sake of explanation, the format in which the system call logs are linked to the identification information of the monitored target and arranged in frequency order is referred to as a "list," but any format is acceptable as long as it is "information obtained by checking the system call logs in chronological order, linking those system call logs to the identification information of the monitored target, and arranging them in frequency order."

[0033] Figure 2 shows the system call profile 200 created by the profile creation unit 120. The profile creation unit 120 creates the system call profile 200 based on the system call lists LFU List 1000 to 1009 shown in Figure 2.

[0034] In Figure 2, let n be the number of elements (list length) in the system call lists LFU Lists 1000 to 1009. This is a parameter that the implementer can arbitrarily determine. In Figure 2, n = 5. Each element of the system call lists LFU Lists 1000 to 1009 records system call identification information (e.g., system call name or system call number). Here, system call identification information is represented by Syscall A, B, C, ... Each element may be empty. For the sake of explanation, the upper and lower parts of the list will be referred to as upper and lower levels, respectively. In the system call list LFU List 1009 on the far right of Figure 2, Syscall B is the highest-level system call, Syscall F is the lowest-level system call, and the system call one level higher than Syscall A is Syscall C.

[0035] The profile creation unit 120 updates the system call list LFU List sequentially in chronological order, from LFU List 1000 to LFU List 1001, from LFU List 1001 to LFU List 1002, ..., from LFU List 1008 to LFU List 1009, based on the system call log. Details on how to update the system call list LFU List and how to create a profile based on it will be described later.

[0036] <Profile Database 130> The profile database 130 stores the system call profiles 200 (Figure 2) created by the profile creation unit 120. The profile database 130 mainly stores profiles created by the profile creation unit 120. The profile database 130 can also store profiles created separately by the implementer. When the profile creation unit 120 or the anomaly detection unit 140 queries the profile database 130, it returns the appropriate profile to the querying source.

[0037] <Anomaly Detection Unit 140> In the "Profile Application Phase," the Anomaly Detection Unit 140 performs anomaly detection by comparing the monitored system call profile with the system call log obtained by the system call collection unit 110 through monitoring.

[0038] First, the anomaly detection unit 140 obtains a profile to be applied to the monitored target from the profile database 130. While the profile is being applied, the anomaly detection unit 140 periodically analyzes the system call log of the monitored target and determines that an anomaly has occurred if it detects behavior that deviates from the profile. For example, if the profile is a list of enumerated lists as in Non-Patent Document 1, an anomaly can be determined if the updated list does not exist in the list. Also, if the profile is a vectorized and clustered list as in Non-Patent Document 2, an anomaly can be determined if the updated list, similarly vectorized, does not belong to any of the clusters. Alternatively, if the profile is a machine learning model, the list or processed information of the list (however, the same information must be used during training) can be input into the learning model to determine whether or not an anomaly has occurred.

[0039] The anomaly detection unit 140 notifies the implementer, security analysis and response system, etc., when it detects an anomaly. Items notified include the identification information of the monitored target and system call, and the time the anomaly occurred.

[0040] The operation of the profiling device 100, configured as described above, will be explained below.

[0041] <Operation of Profile Creation Unit 120> Figure 3 is a flowchart showing the operation of the profile creation unit 120. In step S11, the profile creation unit 120 obtains a system call log from the system call collection unit 110 and extracts system calls related to the monitored target.

[0042] Specifically, in the "profile creation phase," the profile creation unit 120 obtains the collected and recorded system call logs from the system call collection unit 110 and extracts only the system call logs related to the monitored target.

[0043] In step S12, the profile creation unit 120 sequentially checks system calls in the system call log in chronological order. The sequential check of system calls in chronological order is repeated from the loop start of step S12 to the next loop end of step S16 until there are no more system calls to be checked.

[0044] In step S13, the profile creation unit 120 determines whether or not the newly confirmed system call (the subject system call) exists in the system call list (the system call list LFU List in FIG. 2).

[0045] If the subject system call exists in the system call list (S13: Yes), in step S14, the profile creation unit 120 swaps the subject system call and the system call one position higher in the system call list (for example, increases the rank of the subject system call by one. If the subject system call is already at the highest rank, nothing is done), and the process proceeds to step S16.

[0046] If the subject system call does not exist in the system call list (S13: No), in step S15, the profile creation unit 120 inserts the subject system call into an arbitrary element of the system call list, and the process proceeds to step S16.

[0047] The reason for inserting the subject system call into an arbitrary element of the system call list (for example, when the number of elements n=5, the arbitrary element is the 3rd element) is as follows. By inserting the subject system call into an arbitrary element, it can be expected that the system call list will be significantly updated. If insertion is not performed into an arbitrary element and, for example, insertion is only performed into the last element of n elements, only the last element of the system call list is simply rewritten, and there are cases where a significant update of the system call list cannot be expected. However, if the insertion position of an arbitrary element is set to an upper position in the system call list, the frequency information that has been accumulated with great effort will be rewritten, which is not preferable. An arbitrary element is set according to the number of elements n and the tendency of system calls.

[0048] At this time, the originally existing system call may be overwritten, or the ranking of system calls below the insertion position may be lowered one by one to empty the element at the insertion position before inserting the system call. The practitioner may arbitrarily determine the insertion method and insertion position (e.g., lowest position, one position above the lowest, middle position, highest position).

[0049] By inserting the system call into any element of the system call list, the system call list is updated to the latest list. A system call list that is sequentially updated in chronological order is a list that simultaneously considers feature values related to a short period (important system calls that have been recently called) and feature values related to a long period (frequency distribution).

[0050] In step S16, the profile creation unit 120 records the system call list. In the loop processing from step S13 to step S16 described above, when there are no more system calls to be checked, the loop processing is terminated (at the loop end of step S12), and the process proceeds to step S17.

[0051] In step S17, the profile creation unit 120 creates a profile based on the list and set of lists recorded in the profile database 130, and then terminates the processing of this flow.

[0052] The list created in this flow reflects both the most recently issued system calls and the medium- to long-term frequency distribution of system calls (although detailed frequency information is lost, the list is roughly sorted in order of frequency).

[0053] This section describes a specific example of creating the system call list (LFU List) shown in Figure 2. The system call lists (LFU Lists 1000-1009) in Figure 2 have a list length of n=5 and show the update process when the system call identification information is confirmed in the order, for example, Syscall {A, B, C, B, D, B, E, F, C}. This order of identification information, Syscall{A, B, C, B, D, B, E, F, C}, is just one example. Furthermore, the insertion position of the system call described in step S15 of the flow in Figure 3 is set to the lowest level of the list, and this example shows how to overwrite a system call that already exists there.

[0054] • LFU List1000: The system call list LFU List1000 is in its initial state, with each element being empty. LFU List1000 is updated chronologically to LFU List1001 (and similarly for LFU List1002 and subsequent entries).

[0055] - LFU List1001 The newly identified system call identifier Syscall A is added to the system call list LFU List1000 (hereinafter, the newly identified system call identifier will be shown in bold), and it becomes LFU List1001. Since the identifier Syscall A is added to LFU List1000, which is empty, the system call identifier Syscall A is placed at the top of the list in the system call list LFU List1001.

[0056] - LFU List 1002: The newly identified system call identification information Syscall B is added to the system call list LFU List 1001, becoming LFU List 1002. Here, since the insertion position of the system call in step S15 is set to the lowest level, the identification information Syscall B is inserted below the already inserted identification information Syscall A.

[0057] - LFU List 1003: The newly identified system call identifier Syscall C is added to the system call list LFU List 1002, becoming LFU List 1003. Here, since the insertion position of the system call in step S15 is set to the lowest level, the identifier Syscall C is inserted below the already inserted identifier Syscall B.

[0058] The following are characteristics of the creation of the LFU List 1004 system call list. Specifically, if the identification information of a newly identified system call already exists in the LFU List, the list position of that identification information is promoted one level up (this is called "exchange"). For example, in the LFU List 1003 system call list in Figure 2, the identification information Syscall B is in the second-highest list position, and Syscall B is newly identified at this time. In this case, as shown by arrow a in Figure 2, the list position of the identification information Syscall B is raised one level up (in this example, one level up from the identification information Syscall A in LFU List 1004, i.e., the highest level). Therefore, in the LFU List 1004 system call list, the identification information Syscall B is in the highest list position, followed by the identification information Syscall A, and then the identification information Syscall C.

[0059] - LFU List 1005: The newly identified system call identifier Syscall D is added to the system call list LFU List 1004, becoming LFU List 1005. Here, since the insertion position of the system call in step S15 of Figure 3 is set to the lowest level, the identifier Syscall D is inserted below the already inserted identifier Syscall C.

[0060] - LFU List 1006: In Figure 2, the system call list LFU List 1005 has the identification information Syscall B at its top position, and it is assumed that Syscall B has now been newly identified. Since the identification information Syscall B is already at the top of the list, it is not replaced (the status is maintained), and the system call list becomes LFU List 1006.

[0061] - LFU List 1007: The newly identified system call identifier Syscall E is added to the system call list LFU List 1006, becoming LFU List 1007. Here, since the system call insertion position in step S15 of Figure 3 is set to the lowest level, the identifier Syscall E is inserted below the already inserted identifier Syscall D.

[0062] - LFU List1008 attempts to add the newly identified system call identifier Syscall F to the system call list LFU List1007. However, the system call lists LFU List1000 to 1009 have a list length n=5, and there are no empty slots in the list. Here, since the insertion position of the system call in step S15 is set to the lowest position, the identifier Syscall E at the lowest list position in system call list LFU List1007 is overwritten with the identifier Syscall F.

[0063] - LFU List1009 The system call list LFU List1008 has an identifier Syscall C at the third position from the top, and it is assumed that Syscall C has now been identified. In this case, as shown by arrow b in Figure 2, the list position of the identifier Syscall C is moved up by one (in this example, one position above the identifier Syscall A in LFU List1009). Therefore, as shown by the bidirectional arrow c in Figure 2, the system call list LFU List1009 swaps the identifier Syscall C at the third position from the top of LFU List1008 with the identifier Syscall A at the second position.

[0064] The initial state of the list can be arbitrarily determined by the implementer. For example, it can be empty, as in the LFU List1000 example in Figure 2, or it can store any system call. The method for creating the profile can also be arbitrarily determined by the implementer. However, it is necessary to create a profile that is appropriate for the detection method. For example, all unique lists can be enumerated (or listed using a Bloom filter, etc.) as in Non-Patent Document 1, or vectorization and clustering can be performed as in Non-Patent Document 2. Alternatively, a machine learning model can be constructed.

[0065] <Operation of the Anomaly Detection Unit 140> Figure 4 is a flowchart showing the operation of the anomaly detection unit 140.

[0066] In step S21, the anomaly detection unit 140 sequentially checks the system calls that have actually been observed in chronological order. This sequential check of system calls in chronological order is repeated from the start of the loop in step S21 to the end of the next loop in step S26, until there are no more system calls to be observed.

[0067] Specifically, in the "profile application phase," the anomaly detection unit 140 sequentially checks the system calls actually observed in chronological order and updates the system call list in the same way as the profile creation unit 120 in the "profile creation phase." Therefore, steps S13 to S15 in the flow of Figure 3 are the same process as steps S22 to S24 in Figure 4 below. As a result, a system call list LFU List (Figure 2) similar to that of the "profile creation phase" is created in the "profile application phase."

[0068] In step S22, the anomaly detection unit 140 determines whether the system call in question exists in the system call list. If the system call exists in the system call list (S22: Yes), in step S23, the anomaly detection unit 140 swaps the system call in question with the next higher-level system call in the system call list and proceeds to step S25.

[0069] If the system call in question does not exist in the system call list (S22: No), in step S24 the anomaly detection unit 140 inserts the system call into any element of the system call list and proceeds to step S25.

[0070] In step S25, the anomaly detection unit 140 compares the list with the profile. In step S26, the anomaly detection unit 140 determines whether or not there is an anomaly in the computer system 1 (monitored object) based on the result of comparing the list with the profile.

[0071] If an abnormality is detected (S26: Yes), the abnormality detection unit 140 detects and notifies the abnormality in step S27 and proceeds to the end of the loop. If there is no abnormality (S26: No), the abnormality detection unit 140 proceeds to the end of the loop as is. In the loop processing from step S21 to step S27, if there are no more observed system calls and the abnormality determination is completed, the loop processing is terminated (end of the loop in step S21), and the processing of this flow is terminated.

[0072] In steps S25 to S27 described above, the anomaly detection unit 140 compares the updated system call list with the profile to determine whether or not there is an anomaly (for example, a threat). If an anomaly is detected, it notifies the system accordingly, and if there is no anomaly, it checks the next system call (returning to step S22).

[0073] The method for matching the system call list with the profile in step S25 above may be determined arbitrarily by the implementer. However, it is necessary to select a detection method that is appropriate to the nature of the profile. For example, if the profile is a list of enumerated lists as in Non-Patent Document 1, an abnormality can be determined when the updated list is not present in the list.

[0074] Furthermore, when a list is vectorized and clustered to create a profile, as in Non-Patent Document 2, an anomaly can be determined if the updated list, similarly vectorized, does not correspond to any of the clusters.

[0075] Alternatively, when profiling other machine learning models, you can input a list or processed information from a list (however, the same information must be used during training) into the training model to determine whether it is anomaly or not.

[0076] (Second Embodiment) In the second embodiment, similar to the first embodiment, a system call profile of the system to be monitored is created, and anomalies are detected based on it. The first embodiment used a system call list that reflected the frequency distribution of system calls issued over the medium to long term. Therefore, if the medium to long term frequency distribution of the system to be monitored was prone to fluctuations, the detection accuracy may decrease. In the second embodiment, a system call list that reflects the locality of system call issuance is used instead of the medium to long term frequency distribution.

[0077] Figure 5 is a configuration diagram showing a profiling device 100A according to a second embodiment of the present invention. Components identical to those in Figure 1 are denoted by the same reference numerals, and the explanation of the redundant parts is omitted. As shown in Figure 5, the profiling device 100A includes a system call collection unit 110, a profile creation unit 120A, a profile database 130, and an anomaly detection unit 140A.

[0078] <Profile Creation Unit 120A> Similar to the profile creation unit 120 in Figure 1, the profile creation unit 120A, in the "profile creation phase," checks the system call logs input from the system call collection unit 110 in chronological order, associates them with the identification information of the monitored target, and creates a system call profile of the monitored target based on a list arranged in frequency order.

[0079] In the "profile creation phase," the profile creation unit 120A creates a system call profile that reflects the local referentiality of system calls based on the system call log input from the system call collection unit 110 (see Figures 6 and 7). Specifically, if the system call in question exists in the list, the profile creation unit 120A deletes it, then lowers the rank of all other system calls above it by one position until the top position is empty, and then inserts the system call in question at the top. If the system call in question does not exist in the list, the profile creation unit 120A lowers the rank of all system calls already in the list by one position until the top position is empty, and then inserts the system call in question at the top. In this way, a system call profile that reflects local referentiality is created.

[0080] <Anomaly Detection Unit 140A> Similar to the Anomaly Detection Unit 140 in Figure 1, the Anomaly Detection Unit 140A performs anomaly detection in the "Profile Application Phase" based on the monitored system call profile and the system call log obtained by the System Call Collection Unit 110 through monitoring (see Figure 6). Specifically, while applying a system call profile that reflects local referentiality, the Anomaly Detection Unit 140A periodically analyzes the monitored system call log and determines that an anomaly has occurred if it detects behavior that deviates from the profile. For example, if the profile is a list of enumerated lists as in Non-Patent Document 1, it can be determined that an anomaly has occurred if the updated list does not exist in the list. Also, if the profile is a vectorized and clustered list as in Non-Patent Document 2, it can be determined that an anomaly has occurred if the updated list, similarly vectorized, does not belong to any cluster. Alternatively, if other machine learning models are used as the profile, it is also possible to input the list or processed list information (however, the same information must be used during training) into the learning model to determine whether or not an anomaly has occurred.

[0081] Figure 6 shows the system call profile 200A created by the profile creation unit 120A. The same reference numerals are used for components identical to those in Figure 2. In Figure 6, n is the number of elements (list length) in the system call list LRU List 1100 to 1109. This is a parameter that the implementer can arbitrarily determine. In Figure 6, n = 5.

[0082] Each element of the system call lists LRU Lists 1100 to 1109 records system call identification information (e.g., system call name and system call number). Here, system call identification information is represented by Syscall A, B, C, ... Each element may be empty. Based on the system call log, the profile creation unit 120A sequentially updates the system call lists LRU Lists chronologically from LRU List 1100 to LRU List 1101, from LRU List 1101 to LRU List 1102, ..., from LRU List 1108 to LRU List 1109. Based on the system call lists LRU Lists 1100 to 11009 shown in Figure 6, the profile creation unit 120A creates a system call profile 200A that reflects local referentiality.

[0083] • LRU List1100: The system call list LRU List1100 is in its initial state, with each element being empty. LRU List1100 is updated chronologically to LRU List1101 (and similarly for LRU List1102 and subsequent entries).

[0084] - LRU List 1001 The newly identified system call identifier Syscall A is added to the system call list LRU List 1100 (hereinafter, the newly identified system call identifier will be shown in bold), becoming LRU List 1101. Since the identifier Syscall A is added to the empty LRU List 1100, the system call identifier Syscall A is placed at the top of the list in the system call list LRU List 1101.

[0085] ・LRU List 1102 The newly identified system call identifier Syscall B is added to the system call list LRU List 1101, becoming LRU List 1102. Since the system call identifier Syscall B does not exist in the system call list LRU List 1101, the rank of the system call identifier Syscall A is lowered by one position to make the top position empty (symbol d in Figure 6), and then the system call identifier Syscall B is inserted at the top position (symbol e in Figure 6).

[0086] ・LRU List 1103: The newly identified system call identifier Syscall C is added to the system call list LRU List 1102, becoming LRU List 1103. Since the system call identifier Syscall C does not exist in the system call list LRU List 1102, the rank of system call identifiers Syscall B and Syscall A is lowered by one position each until the top position is empty (symbol f in Figure 6), and then system call identifier Syscall C is inserted at the top position (symbol g in Figure 6).

[0087] - LRU List 1104: In the system call list LRU List 1103, the rank of system call identifiers Syscall C and Syscall B is lowered by one position each until the top position is empty, and then the newly identified system call identifier Syscall A is moved to the top position.

[0088] ・LRU List 1105 The newly identified system call identifier Syscall D is added to the system call list LRU List 1104, becoming LRU List 1105. Since the system call identifier Syscall D does not exist in the system call list LRU List 1104, the ranks of the system call identifiers Syscall A, Syscall C, and Syscall B in the system call list LRU List 1104 are lowered by one position each until the top position is empty (symbol h in Figure 6), and then the system call identifier Syscall D is inserted at the top position (symbol i in Figure 6).

[0089] Similarly, for system call lists LRU Lists 1106 to 1109, if the system call in question exists in the list, it is deleted, the rank of all other system calls above it is lowered by one position until the top position is empty, and then the system call in question is inserted at the top. If the system call in question does not exist in the list, the rank of all system calls already in the list is lowered by one position until the top position is empty, and then the system call in question is inserted at the top. This creates a system call profile 200A that reflects local referentiality.

[0090] The initial state of the list can be arbitrarily determined by the implementer. For example, it can be empty, as in the example of LRU List 1100 in Figure 6, or it can store any system call. The method of creating the profile can also be arbitrarily determined by the implementer. However, it is necessary to create a profile that is appropriate for the detection method. For example, all unique lists can be enumerated (or listed using a Bloom filter, etc.) as in Non-Patent Document 1, or vectorization and clustering can be performed as in Non-Patent Document 2. Alternatively, a machine learning model can be constructed.

[0091] The operation of the profiling device 100A, configured as described above, will now be explained. The profile creation unit 120A, in the "profile creation phase," creates a system call profile that reflects local referentiality based on the system call log input from the system call collection unit 110. This operation is almost the same as that of the profile creation unit 120 in Figure 3, so its explanation will be omitted. However, if the system call in question exists in the list, the profile creation unit 120A deletes it, lowers the rank of all other system calls above it by one position until the top position is empty, and then inserts the system call in question at the top position. If the system call in question does not exist in the list, the rank of all system calls already in the list is lowered by one position until the top position is empty, and then inserts the system call in question at the top position. In this way, a system call profile that reflects local referentiality is created.

[0092] The list created by the profile creation unit 120A reflects the most recently issued system calls, particularly their locality. Note that methods other than those described in the first and second embodiments may be used to update the list.

[0093] <Operation of the Anomaly Detection Unit 140A> Figure 7 is a flowchart showing the operation of the Anomaly Detection Unit 140A. The same reference numerals are used for components identical to those in Figure 6, and the explanation of the redundant parts is omitted.

[0094] In step S22, the anomaly detection unit 140A determines whether or not the system call exists in the system call list.

[0095] If the system call in question exists in the system call list (S22: Yes), in step S31 the anomaly detection unit 140A clears the top position in the system call list, moves the system call in question to the top position, and proceeds to step S25.

[0096] If the system call in question does not exist in the system call list (S22: No), in step S32 the anomaly detection unit 140A clears the top position in the system call list and inserts the system call in question at the top position, then proceeds to step S25.

[0097] In step S25, the anomaly detection unit 140A compares the list with the profile. In step S26, the anomaly detection unit 140A determines whether or not there is an anomaly in the computer system 1 (monitoring target) based on the result of comparing the list with the profile.

[0098] If an abnormality is detected (S26: Yes), in step S27 the abnormality detection unit 140 detects and notifies of the abnormality and proceeds to the end of the loop. If there is no abnormality (S26: No), in step S27 the abnormality detection unit 140 proceeds to the end of the loop as is. In the loop processing from step S21 to step S27, if there are no more observed system calls and the abnormality determination is completed, the loop processing is terminated (end of the loop in step S21), and the processing of this flow is terminated.

[0099] In steps S25 to S27 described above, the anomaly detection unit 140 compares the updated system call list with the profile to determine whether or not there is an anomaly (for example, a threat). If an anomaly is detected, it notifies the system accordingly, and if there is no anomaly, it checks the next system call (returning to step S22).

[0100] The method for matching the system call list with the profile in step S25 above may be determined arbitrarily by the implementer. However, it is necessary to select a detection method that is appropriate to the nature of the profile. For example, if the profile is a list of enumerated lists as in Non-Patent Document 1, an abnormality can be determined when the updated list is not present in the list.

[0101] Furthermore, when a list is vectorized and clustered to create a profile, as in Non-Patent Document 2, an anomaly can be determined if the updated list, similarly vectorized, does not correspond to any of the clusters.

[0102] Alternatively, when profiling other machine learning models, you can input a list or processed information from a list (however, the same information must be used during training) into the training model to determine whether it is anomaly or not.

[0103] The anomaly detection unit 140A may, like the profile creation units 120 and 120A, employ a method for updating the list other than those described in the first and second embodiments. In that case, it is preferable that the same update method is used for both the profile creation units 120 and 120A and the anomaly detection units 140 and 140A.

[0104] (Third Embodiment) Whether to use the first or second embodiment depends on the system being monitored (more specifically, on the system call characteristics of the system being monitored). Similarly, various parameters related to the method (e.g., list length, method of inserting new elements, and insertion position) also depend on the system being monitored.

[0105] Therefore, in the third embodiment, a "method identification unit" is introduced to identify a method more suitable for the monitoring target. This embodiment can also be used in conjunction with the fourth embodiment described later.

[0106] Figure 8 is a configuration diagram showing a profiling device 100B according to a third embodiment of the present invention. Components identical to those in Figures 1 and 5 are denoted by the same reference numerals, and the explanation of the redundant parts is omitted. As shown in Figure 8, the profiling device 100B includes a system call collection unit 110, profile creation units 120, 120A, a profile database 130, anomaly detection units 140, 140A, and a method identification unit 150.

[0107] The method identification unit 150 can also select a better method than the one currently in use during the "profile application phase" and switch methods at any time. For example, in response to alerts (e.g., anomaly detection notifications) issued daily by the anomaly detection units 140 and 140A, the implementer can determine whether or not it was a correct alert and input this information to the anomaly detection units 140 and 140A or the method identification unit 150. In this way, the profiling device 100B can calculate various performance indicators such as the true positive rate and the false positive rate. Then, when the profiling device 100B determines from the calculated performance indicators that performance has deteriorated, it can again select a better method using the profiling methods described in the first and second embodiments.

[0108] The operation of the profiling device 100B configured as described above will be explained below. The operation of the method identification unit 150 in the "profile creation phase" will be described. The user can arbitrarily set up multiple methods to be compared in advance. For example, in the first embodiment, (1) a method that inserts a new element at the bottom of the system call list, (2) a method that lowers the rank of the 10 elements from the bottom of the system call list by one (at which point the lowest element is deleted) and inserts a new element in the empty space, (3) a method that lowers the rank of the 20 elements from the bottom of the system call list by one (at which point the lowest element is deleted) and inserts a new element in the empty space, as well as the method in the second embodiment, etc. Further patterns of methods with different list lengths may be added here.

[0109] The method identification unit 150 observes the processing content of the profile creation units 120 and 120A and the created profiles, and selects a method that can create a better profile. Here, the quality of the profile can be judged based on factors such as profile size, detection accuracy, and detection speed. However, measuring detection accuracy and detection speed may require malicious system call logs, etc., which should be prepared by the implementer as appropriate. For example, one could select a method that results in the smallest profile size, or one could write a separate objective function that considers multiple parameters such as detection accuracy and detection speed, and select a method that maximizes (or minimizes) that value.

[0110] (Fourth Embodiment) In the fourth embodiment, similar to the first and second embodiments, a system call profile of the monitored system is created and anomalies are detected based on it. Furthermore, the fourth embodiment proposes security countermeasures and performs automatic security control based on the detection results.

[0111] The first and second embodiments are examples of applications up to the point of detecting an anomaly (e.g., a threat). In the fourth embodiment, after detecting an anomaly, suggestions for security countermeasures are made or security countermeasures are automatically executed based on the results.

[0112] Figure 9 is a configuration diagram showing a profiling device 100C according to a fourth embodiment of the present invention. Components identical to those in Figures 1 and 5 are denoted by the same reference numerals, and the explanation of the redundant parts is omitted. As shown in Figure 9, the profiling device 100C comprises a system call collection unit 110, profile creation units 120, 120A, a profile database 130, anomaly detection units 140, 140A, and a profile control unit 160.

[0113] The profile control unit 160 retrieves a profile to be applied to the monitored target from the database and selects it appropriately. In the first and second embodiments, this was done directly by the anomaly detection units 140 and 140A, and this format is also acceptable.

[0114] If multiple profiles are applicable to the monitored target, for example, the latest profile should be applied. Alternatively, if multiple profiles can be applied, the one with the fewest system calls to monitor may be applied. Such policies should be determined in advance by the implementer.

[0115] The profile control unit 160 selects the profile to be monitored and then notifies the anomaly detection units 140 and 140A of this. At this time, for example, identification information of the monitored targets and a list of profiles (correspondence table) applied to each monitored target are input to the anomaly detection units 140 and 140A.

[0116] When the profile control unit 160 receives notification from the anomaly detection units 140 and 140A that an anomaly has occurred, it takes appropriate action on the computer system 1 (Figure 9) in accordance with a policy pre-set by the implementer. Appropriate action may include, for example, forcibly killing the process that issued the unauthorized system call, forcibly logging out the user who issued the unauthorized system call, or simply recording the log of the unauthorized system call (without interfering with the system call issuer). However, the information necessary for such action (for example, identification information of the issuing process or user) must be pre-set to be collected by the system call collection unit.

[0117] [Hardware Configuration] The profiling devices 100, 100A, 100B, and 100C according to the above embodiment (Figures 1, 5, 8, and 9) are implemented by a computer 900 having a configuration such as that shown in Figure 10. Figure 10 is a hardware configuration diagram showing an example of a computer 900 that implements the functions of the profiling devices 100, 100A, 100B, and 100C. The computer 900 has a CPU 901, a ROM 902, a RAM 903, an HDD 904, a communication interface 906, an input / output interface 905, and a media interface 907.

[0118] The CPU 901 operates based on programs stored in the ROM 902 or HDD 904, and controls the profiling devices 100, 100A, 100B, and 100C shown in Figures 1, 5, 8, and 9. The ROM 902 stores boot programs executed by the CPU 901 when the computer 900 starts up, as well as programs that depend on the computer 900's hardware.

[0119] The CPU 901 controls input devices 910, such as a mouse or keyboard, and output devices 911, such as a display, via an input / output interface 905. The CPU 901 acquires data from the input devices 910 via the input / output interface 905 and outputs the generated data to the output devices 911. In addition to the CPU 901, a GPU (Graphics Processing Unit) or the like may also be used as a processor.

[0120] The HDD 904 stores programs executed by the CPU 901 and data used by those programs. The communication interface 906 receives data from other devices via the network 920, which is a communication network, and outputs it to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.

[0121] 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 related to the desired processing 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 Disc) or PD (Phase change rewritable 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.

[0122] For example, when computer 900 functions as a profiling device 100, 100A, 100B, 100C (Figures 1, 5, 8, and 9) configured as one of the devices according to this embodiment, the CPU 901 of computer 900 realizes the functions of the profiling devices 100, 100A, 100B, and 100C by executing a program loaded onto RAM 903. Furthermore, data from RAM 903 is stored in HDD 904. CPU 901 reads and executes a program related to the target processing from recording medium 912. Alternatively, CPU 901 may read a program related to the target processing from another device via a communication network 920.

[0123] [Effects] As described above, the profiling devices 100, 100A, 100B, and 100C (Figures 1, 5, 8, and 9) are profiling devices that use system call profiling and include a system call collection unit 110 (Figures 1, 5, 8, and 9) that collects and monitors system calls issued by the monitored target (computer system 1), a profile creation unit 120 (Figures 2 and 6) that checks the system call logs collected by the system call collection unit 110 in chronological order, links them with the identification information of the monitored target, and creates system call profiles 200 and 200A (Figures 2 and 6) based on a list arranged in frequency order, and an anomaly detection unit 140 (Figures 1, 5, 8, and 9) that compares the system call profile of the monitored target with the system call logs obtained by the system call collection unit 110 to perform anomaly detection.

[0124] As described in the problem to be solved, there are two detection methods: one that considers only features related to short periods using sequences (Non-Patent Literature 1), and another that considers features related to frequency distributions (Non-Patent Literature 2). When only features related to short periods are considered, changes in frequency distributions over longer periods are easily overlooked. On the other hand, when only features related to frequency distributions are considered, critical system calls that are called infrequently are easily overlooked. However, simply combining the two detection methods results in large overhead and a significant impact on the performance of the monitored object. Profiling devices 100, 100A, 100B, and 100C are inventions relating to detection (profile creation) that considers these two types of features.

[0125] In other words, the profiling devices 100, 100A, 100B, and 100C, for system call sequences, check system call logs in chronological order to associate features related to short periods (e.g., the most recent critical system call) with the identification information of the monitored target, and simultaneously consider features related to long periods (e.g., frequency distribution) by arranging them in a list format in order of frequency. This enables accurate threat detection. Furthermore, it reduces overhead and minimizes performance impact compared to simply combining the two detection methods described above.

[0126] As a secondary effect, the profiling devices 100, 100A, 100B, and 100C can reduce the computational cost required for profile creation and detection. The reason for this is as follows: The total number of unique (length n) system call lists enumerated in this invention is generally considered to be less than the total number of unique n-grams enumerated in sequence-based detection methods. In other words, the profiles of this embodiment are smaller in size than those of sequence-based methods, and the computational cost required for profile creation and detection is reduced.

[0127] Frequency-based detection methods require aggregating a large number of system calls (at least 100 to 1000 in number) that have been invoked in the past each time to calculate the frequency distribution. However, in this invention, it is only necessary to update the list sequentially, thus reducing the computational cost required for profiling and detection.

[0128] In the profiling devices 100, 100A, 100B, and 100C (Figures 1, 5, 8, and 9), the profile creation units 120 and 120A create a system call list that simultaneously reflects, for a system call sequence input in time series, features related to a shorter period than a predetermined timeframe, including the most recently invoked system call (particularly critical system calls), and features related to a longer period than a predetermined timeframe, including the frequency distribution, and output it as a system call profile 200 and 200A.

[0129] By doing so, the system call profiles 200 and 200A will reflect both the most recently issued system calls and the frequency distribution of system calls over the medium to long term (although detailed frequency information will be lost, they will be roughly sorted by frequency). As a result, the profiling devices 100, 100A, 100B, and 100C will not overlook changes in frequency distribution over longer periods, nor critical system calls that are invoked infrequently, enabling more accurate threat detection.

[0130] In the profiling devices 100, 100A, 100B, and 100C (Figures 1, 5, 8, and 9), the anomaly detection units 140 and 140A compare the system call lists of system call profiles 200 and 200A stored in the profile storage unit with a system call list that simultaneously reflects features related to a shorter period than predetermined, including the most recently invoked system call (particularly critical system calls), and features related to a longer period than predetermined, including frequency distributions, for system call sequences input in chronological order. If behavior deviating from the system call profiles 200 and 200A is detected, the unit determines that an anomaly has occurred.

[0131] By doing so, the profiling devices 100, 100A, 100B, and 100C ensure that the system call lists in system call profiles 200 and 200A reflect both the most recently issued system calls and the medium- to long-term frequency distribution of system calls. As a result, the profiling devices 100, 100A, 100B, and 100C can detect anomalies more accurately without overlooking changes in frequency distribution over longer periods or critical system calls that are invoked infrequently.

[0132] Furthermore, among the processes described in each of the above embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically by known methods. In addition, the processing procedures, control procedures, specific names, and information including various data and parameters shown in the above documents and drawings can be changed at will unless otherwise specified. Moreover, each component of each illustrated device is a functional concept and does not necessarily have to be physically configured as shown. In other words, the specific forms of distribution and integration of each device are not limited to those shown, and all or part of them can be functionally or physically distributed and integrated in any unit according to various loads and usage conditions.

[0133] Furthermore, each of the above configurations, functions, processing units, and processing means may be implemented in hardware, either partially or entirely, by designing them as integrated circuits, for example. Alternatively, each of the above configurations and functions may be implemented in software for the processor to interpret and execute programs that realize each function. Information such as programs, tables, and files that realize each function can be stored in memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC (Integrated Circuit) card, an SD (Secure Digital) card, or an optical disc.

[0134] 1. Computer System (Monitored Object) 100, 100A, 100B, 100C Profiling Device 110 System Call Collection Unit 120, 120A Profile Creation Unit 130 Profile Database (Profile Storage Unit) 140, 140A Anomaly Detection Unit 150 Method Identification Unit 160 Profile Control Unit 200, 200A System Call Profile LFU List, LRU List System Call List Syscall System Call Identification Information (Features)

Claims

1. A profiling device using system call profiling, comprising: a system call collection unit that collects and monitors system calls issued by a target to be monitored; a profile creation unit that checks the system call logs collected by the system call collection unit in chronological order, links them with the identification information of the target to be monitored, and creates a system call profile based on a list arranged in frequency order; and an anomaly detection unit that performs anomaly detection by comparing the system call profile of the target to be monitored with the system call logs obtained by the system call collection unit through monitoring.

2. The profiling device according to claim 1, characterized in that the profile creation unit creates a system call list that simultaneously reflects, for a system call sequence input in time series, features a feature quantity relating to a shorter period than predetermined, including the most recently invoked system call, and features quantity relating to a longer period than predetermined, including the frequency distribution, and outputs it as the system call profile.

3. The profiling device according to claim 1, wherein the anomaly detection unit compares the system call list of the system call profile stored in the profile storage unit with a system call list that simultaneously reflects, for a system call sequence input in chronological order, features a feature quantity relating to a period shorter than a predetermined time, including the most recently invoked system call, and features quantity relating to a period longer than a predetermined time, including the frequency distribution, and determines that an anomaly has occurred if behavior deviating from the system call profile is detected.

4. A program that causes a computer, acting as a profiling device using system call profiling, to execute a system call collection procedure for collecting and monitoring system calls issued by a target; a profile creation procedure for reviewing the collected system call logs in chronological order, linking them with the identification information of the target, and creating a system call profile based on the resulting list sorted by frequency; and an anomaly detection procedure for comparing the system call profile of the target with the input system call logs to perform anomaly detection.

Images