Inspection device, management method, and program

Abstract

The purpose of the present disclosure is to provide an inspection device, a management method, and a program capable of reducing the inspection load of software. An inspection device according to the present disclosure comprises: an acquisition unit that acquires management information in which identification information of software and a list of functions, which are a start point of inspection and an end point of inspection, included in the software are associated with each other; and a management unit that manages the management information, the management unit managing, as inspected software, identification information of inspection target software associated with the list after inspection of the inspection target software.

Description

Inspection device, management method and program

[0001] The present disclosure relates to an inspection device, a management method, and a program.

[0002] In recent years, there has been an increase in cases where software has been contaminated with malicious functions, and therefore it is necessary to inspect software for the presence of malicious functions before shipping or when receiving the software.

[0003] Patent Document 1 discloses the configuration of a software monitoring device that uses policy information. The software management device in Patent Document 1 inspects the behavior of monitored software based on policy information acquired from a policy information storage unit. The software management device detects unexpected behavior of the monitored software that is not specified in the policy information.

[0004] Japanese Patent Application Laid-Open No. 2006-053788

[0005] In many cases, malicious functions contained in software are not executed during normal processing, but are executed when specific data is input. Therefore, when the software monitoring device disclosed in Patent Document 1 detects unexpected behavior of monitored software, the amount of policy information stored in the policy information becomes enormous. In this case, the software monitoring device must inspect the monitored software based on the policy information every time the software is executed, which increases the inspection burden.

[0006] In view of the above-mentioned problems, an object of the present disclosure is to provide an inspection device, a management method, and a program that can reduce the burden of software inspection.

[0007] The inspection device of the present disclosure includes an acquisition unit that acquires management information that associates software identification information with a list of functions contained in the software that are the starting point of the inspection and a list of functions that are the end point of the inspection, and a management unit that manages the management information, and after inspection of the software to be inspected is completed, the management unit manages the identification information of the software to be inspected that is associated with the list as inspected software.

[0008] The management method disclosed herein acquires management information that associates software identification information with a list of functions contained in the software that are the starting point of the inspection and a list of functions that are the end point of the inspection, manages the management information, and after inspection of the software to be inspected is completed, manages the identification information of the software to be inspected that is associated with the list as inspected software.

[0009] The program disclosed herein causes a computer to acquire management information that associates software identification information with a list of functions contained in the software that are the starting point of the inspection and a list of functions that are the end point of the inspection, manage the management information, and, after inspection of the software to be inspected is completed, manage the identification information of the software to be inspected that is associated with the list as inspected software.

[0010] The present disclosure makes it possible to provide an inspection device, a management method, and a program that can reduce the burden of software inspection.

[0011] FIG. 1 shows an example of the configuration of an inspection device that inspects software. FIG. 2 shows a flowchart of the management process executed by the inspection device. FIG. 3 shows an example of the configuration of the inspection device. FIG. 4 shows the dependency relationship of libraries that the binary to be inspected imports directly or indirectly. FIG. 5 shows the calling relationship of functions included in each library. FIG. 6 shows a source function list when a syscall is a system call instruction that accepts external input. FIG. 7 shows a sink function list when a syscall is a system call instruction that executes a process that may have a significant impact on security. FIG. 8 shows a knowledge list. FIG. 9 shows a list of inspected binaries or libraries. FIG. 10 is a flowchart showing the inspection process executed by the inspection device. FIG. 11 shows the flow of the inspection process. FIG. 12 shows the flow of the inspection process. FIG. 13 shows a confirmed binary list. FIG. 14 shows the flow of the policy creation process. FIG. 15 shows the flow of the inspection process. FIG. 16 shows the flow of the inspection process. FIG. 17 is a block diagram showing an example of the configuration of an inspection device.

[0012] (First Embodiment) FIG. 1 shows an example of the configuration of an inspection device 10 that inspects software. The inspection device 10 may be a computer device that operates by a processor executing a program stored in a memory. The inspection device may be, for example, a server device. The software inspection may be, for example, the inspection of binaries that represent the software code. Alternatively, the software inspection may be the inspection of libraries imported into the binaries. Furthermore, the library may include binaries that are used by other software in the form of individual binaries, in addition to binaries that are generally used by multiple software programs.

[0013] The inspection device 10 has an acquisition unit 11 and a management unit 12. The acquisition unit 11 and the management unit 12 may be software or modules that perform processing when a processor executes a program stored in a memory, or may be hardware such as a circuit or a chip.

[0014] The acquisition unit 11 and the management unit 12 may both be mounted on the inspection device 10, or may each be mounted on a different computer device. When the acquisition unit 11 and the management unit 12 are mounted on different computer devices, the respective computer devices may constitute an inspection system.

[0015] The acquisition unit 11 acquires management information that associates software identification information with a list of functions included in the software that are the start point of the inspection and a list of functions that are the end point of the inspection. Here, the software to be inspected is software that is the target of inspection, and may be a binary or a library to be inspected. The inspection may be determining whether the software contains a malicious function or a function that may be a malicious function. The inspection may also be detecting a trigger such as a conditional branch that triggers the execution of the above-mentioned malicious function or a function that may be a malicious function. The malicious function may be, for example, a backdoor. In other words, the inspection may be detecting a backdoor trigger.

[0016] The software identification information is information that uniquely identifies the software. The software identification information may be, for example, name information of the software assigned by an administrator or the like. Alternatively, the software identification information may be a hash value of the software.

[0017] The function that is the starting point of the inspection may be rephrased as the function that is the starting point of the analysis. The function that is the starting point of the inspection may also be called a source function. The source function may be a function that receives input from the outside. Receiving input from the outside may be, for example, receiving data from a network.

[0018] The function that is the end point of the inspection may be rephrased as the function that is the end point of the analysis. Also, the function that is the end point of the inspection may be called a sink function. The sink function may be a function that may have a significant impact on security. The function that may have a significant impact on security may be a function that executes a command such as a shell command, a function that reads and writes a file, or a function that includes a predetermined system call command.

[0019] The list of functions that are the starting point of the check and the list of functions that are the end point of the check may be different lists. Alternatively, the list of functions that are the starting point of the check and the list of functions that are the end point of the check may be included in the same list, associated with information indicating which function it is. The list includes the names of the functions.

[0020] The management information may be, for example, a record in which software identification information and a list of functions are associated with each other. One piece of software identification information may be associated with one function or with multiple functions. Also, one function may be associated with multiple pieces of software identification information.

[0021] Acquiring the management information may mean accepting input of the management information. For example, the acquisition unit 11 may acquire or accept management information input from an administrator of the inspection device 10, etc. Alternatively, acquiring the management information may mean receiving management information generated within the inspection device 10. Alternatively, acquiring the management information may mean receiving management information from another device via a network. Alternatively, acquiring the management information may mean generating the management information. For example, the acquisition unit 11 may generate the management information.

[0022] The management unit 12 manages the management information. "Managing" may mean storing, recording, or memorizing the management information acquired by the acquisition unit 11 in a memory or the like within the inspection device 10. "Managing" may also mean executing a process to update, add, or delete the management information.

[0023] After completing the inspection of the software to be inspected, the management unit 12 manages the identification information of the software to be inspected associated with the list as inspected software. The management unit 12 may add the identification information of the software to be inspected whose inspection has been completed to the list that manages the identification information of the inspected software.

[0024] Next, the flow of the management process executed in the inspection device 10 will be described with reference to Fig. 2. Fig. 2 shows a flowchart of the management process executed in the inspection device 10.

[0025] First, the acquisition unit 11 acquires management information that associates software identification information with a list of functions included in the software that are the start point of the inspection and a list of functions that are the end point of the inspection (S11). Next, the management unit 12 manages the management information (S12). Next, after the inspection of the software to be inspected is completed, the management unit 12 manages the identification information of the software to be inspected as inspected software (S13).

[0026] As described above, the inspection device 10 manages a list of functions that are the starting point of the inspection and a list of functions that are the end point of the inspection. Furthermore, after the inspection of the software to be inspected is completed, the inspection device 10 manages the identification information of the software to be inspected as inspected software. This allows the inspection device 10 to avoid inspecting the software to be inspected again, for example, if the software to be inspected is already managed as inspected software.

[0027] Furthermore, the inspection device 10 can use a list of functions managed in association with the identification information of inspected software when inspecting software. For example, when inspecting uninspected software, among multiple functions included in the uninspected software, a function included in the list of functions managed in association with the identification information of inspected software may be identified as a function that will be the start or end point of the inspection. This allows the inspection device 10 to reduce the inspection man-hours when inspecting uninspected software compared to when analyzing all functions to determine whether they are functions that can be the start or end point of the inspection before inspecting.

[0028] (Embodiment 2) Fig. 3 shows an example of the configuration of an inspection device 20. The inspection device 20 in Fig. 3 has a configuration in which an inspection unit 21 is added to the inspection device 10 in Fig. 1. In describing the inspection device 20, detailed description of functions and operations that are the same as those of the inspection device 10 in Fig. 1 will be omitted.

[0029] 3 will be described as an example in which the acquisition unit 11 generates a source function list and a sink function list. The source function list and the sink function list may be generated using the dependency relationships of libraries that the inspection target binary directly or indirectly imports. The source function list and the sink function list may also be referred to as a policy.

[0030] 4 is a diagram showing the dependency relationships of libraries that a binary to be inspected imports directly or indirectly. Fig. 4 shows that the binary to be inspected directly imports library A (libA), library B (libB), and library C (libC). The direct import of libA, libB, and libC into the binary to be inspected may mean that libA, libB, and libC are incorporated into the binary to be inspected, or libA, libB, and libC are included in the binary to be inspected.

[0031] Furthermore, Figure 4 shows that libA imports libC, and libB imports library D (libD). Furthermore, Figure 4 shows that libD imports library E (libE), and libC imports library F (libF). Libraries imported into the binary to be inspected and libraries imported into the library may be referred to as sub-software, sub-binary, etc. Furthermore, the diagram showing the library dependency relationships as shown in Figure 4 may be referred to as a library tree or a binary tree.

[0032] FIG. 5 is a diagram showing the calling relationships of functions included in each library. When identifying functions to be included in the source function list or the sink function list, the acquisition unit 11 first identifies functions including a predetermined system call instruction. The predetermined system call instruction may be, for example, a system call instruction that accepts an external input or a system call instruction that executes a process that may have a serious impact on security. The system call instruction that accepts an external input or a system call instruction that executes a process that may have a serious impact on security may be listed in advance. In other words, the predetermined list may include at least one system call instruction that accepts an external input or a system call instruction that executes a process that may have a serious impact on security. The acquisition unit 11 may identify functions that include a system call instruction that is the same as at least one system call instruction included in the list as functions to be included in the source function list or the sink function list.

[0033] For example, the acquisition unit 11 identifies, as predetermined system call instructions, syscall1 called by lib_func_1 included in libE and syscall2 called by lib_func_2 included in libF. Furthermore, the acquisition unit 11 extracts functions related to syscall1 and syscall2. The functions related to syscall1 may be, for example, lib_func_1 that calls syscall1, lib_func_D that calls lib_func_1, lib_func_B that calls lib_func_D, and func_0 that calls lib_func_B, identified by call flow analysis. lib_func_D is a function included in libD, lib_func_B is a function included in libB, and func_0 is a function included in the binary to be inspected. The function related to syscall2 may be lib_func_2 that calls syscall2, lib_func_C that calls lib_func_2, lib_func_A and func_0 that call lib_func_C, or func that calls lib_func_A and func_0, identified by call flow analysis. lib_func_C is a function included in libC, lib_func_A is a function included in libA, and func is a function included in the binary to be inspected.

[0034] For example, if syscall1 is a system call instruction that accepts an external input, the acquisition unit 11 may include lib_func_1, lib_func_D, lib_func_B, and func_0 associated with syscall1 in the source function list. Furthermore, if syscall1 is a system call instruction that executes a process that may have a significant impact on security, the acquisition unit 11 may include lib_func_1, lib_func_D, lib_func_B, and func_0 associated with syscall1 in the sink function list. Functions associated with syscall2 may also be included in the source function list or the sink function list, depending on whether the system call instruction accepts an external input or executes a process that may have a significant impact on security.

[0035] FIG. 6 shows a source function list for a system call instruction where syscall1 accepts external input. The source function list manages records associating a binary name or library name with a function name and a binary hash. The binary name or library name may be the file name of a binary file or library file, or a uniquely identifiable identifier. In other words, the source function list manages records associating a binary name or library name with a function name and a binary hash. A binary name identifying the binary to be inspected may be registered for the binary to be inspected. The source function list may also manage information useful for inspection, such as an argument number indicating the number of the argument to which the external input is passed in the function, or information indicating whether the external input is via a network, file, or standard input. The binary hash may be a hash value obtained from a hash function by inputting the binary or library into the hash function. The hash value is used as information uniquely identifying the binary or library and also indicates that the binary has not been tampered with or otherwise altered. Furthermore, even if the binary name is the same, the binary hash value will be different if the binary version is different.

[0036] 7 shows a sink function list when syscall2 is a system call instruction that executes a process that may have a serious impact on security. The sink function list manages a binary name or library name, a function name, and a binary hash in association with each other. The sink function list may also manage information useful for inspection, such as arguments that require attention in the function, such as an argument number indicating which argument leads to a process that may have a serious impact on security, or a score indicating the risk of the impact.

[0037] The management unit 12 manages the source function list and the sink function list. For example, the management unit 12 may store the source function list and the sink function list in a memory within the inspection device 20. Furthermore, the management unit 12 may add, delete, and update the source function list and the sink function list to the memory.

[0038] The inspection unit 21 performs an inspection to determine whether the inspection target binary contains any malicious functions or functions that may be malicious functions. The inspection unit 21 may inspect the inspection target binary by analyzing the processing flow. For example, the inspection unit 21 analyzes the processing flow between functions included in the inspection target binary, which are included in the source function list, and functions included in the sink function list, based on information restored from the inspection target binary using a binary analysis tool or the like. The processing flow may be referred to as a control flow or a data flow.

[0039] Data flow analysis is an analysis of which variables or operations in a program an external input propagates to. Data flow analysis may also be an examination of whether there is a flow in which data input in a source function propagates to a sink function that may have a significant impact on security. Data flow analysis may be specified using information called knowledge. The knowledge may be a list of functions that propagate data. The knowledge may be generated in the acquisition unit 11, similar to the source function list and the sink function list.

[0040] Here, the knowledge list will be explained. FIG. 8 shows a knowledge list. The knowledge list in FIG. 8 manages binary hashes, binary names or library names, function names, input argument numbers, and output argument numbers in association with each other. The knowledge list is used, for example, when performing data flow analysis. If the data being analyzed is used as an argument of a function, and if a corresponding function is found in the knowledge list and the data is referenced by the input argument number, the inspection unit 21 determines that the data is propagated to the output argument number. Therefore, by using the knowledge list, the inspection unit 21 can determine that data is being propagated and the propagation destination without having to analyze the inside of the function.

[0041] Control flow analysis is the analysis of the control relationship between variables and processes, and may be the inspection of whether there is a flow in which a sink function is executed when data input to a source function satisfies a specific condition. The analysis of the process flow may be performed by an inspector using a process flow analysis engine, software that performs inspection, etc. The inspection unit 21 is not limited to the analysis of the process flow, and may inspect the binary to be inspected using other general methods.

[0042] Furthermore, when inspecting a binary to be inspected, the inspection unit 21 may inspect libraries that the binary to be inspected directly or indirectly imports. Furthermore, if the inspection unit 21 does not use a source function list and a sink function list, it may extract all functions included in the binary to be inspected or the library to be inspected, and determine functions that satisfy a predetermined condition as source functions or sink functions. The predetermined condition may be a condition that analyzes the processing of each function and determines that a function is a source function if it performs processing that accepts external input, or a sink function if it performs processing that may have a significant impact on security. In this case, the inspection unit 21 analyzes the processing flow between the source functions and sink functions. In an inspection performed by the inspection unit 21 without using a source function list and a sink function list, the processing of all functions included in the binary to be inspected is analyzed. As a result, an inspection performed without using a source function list and a sink function list requires more processing to determine whether a function is a source function or a sink function, and the number of processing flows to be analyzed increases compared to an inspection performed using a source function list and a sink function list. Therefore, a test performed without using the source function list and the sink function list will take longer than a test performed with the source function list and the sink function list.

[0043] The management unit 12 may manage binaries or libraries that have been successfully inspected as inspected binaries or libraries. FIG. 9 shows a list of inspected binaries or libraries. The list of inspected binaries or libraries is managed by associating binary hashes with binary names or library names. FIG. 9 shows that, for example, libF and libE are managed as inspected libraries.

[0044] Next, a description will be given of the flow of the inspection process executed by the inspection device 20. FIG.

[0045] First, the inspection unit 21 determines whether or not the verification of all binaries to be inspected has been completed (S21). The completion of the verification may mean that it has been determined after the inspection that there is a problem in the inspection result.

[0046] If the inspection unit 21 determines that all binaries have been checked, it ends the process. If the inspection unit 21 determines that all binaries have not been checked, it selects one unchecked binary (S22). The selected binary is treated as an inspection target binary that will be inspected.

[0047] The inspection unit 21 determines whether the binary to be inspected is included in the inspected binary list managed by the management unit 12 (S23). If the inspection unit 21 determines that the binary to be inspected is included in the inspected binary list, the inspection unit 21 treats the binary to be inspected as a confirmed binary (S25) and repeats the processing from step S21 onwards.

[0048] In step S23, if the inspection unit 21 determines that the binary to be inspected is not included in the inspected binary list, it starts the inspection process (S24). After the inspection of the binary to be inspected is completed, the inspection unit 21 marks the binary to be inspected as a confirmed binary (S25). Step S24 indicates that it is a recursive process, and after the inspection process is completed, the processes from step S24 onwards are executed.

[0049] The inspection process executed in step S24 will now be described in detail with reference to Figures 11 and 12. Figures 11 and 12 are diagrams showing the flow of the inspection process.

[0050] First, the inspection unit 21 extracts a group of binaries directly imported by the binary to be inspected or the library to be inspected (S31). The group of binaries may include binaries or libraries. In the example of FIG. 4, the inspection unit 21 extracts libA, libB, and libC as the group of binaries to be inspected. Next, the inspection unit 21 determines whether or not confirmation of all extracted binaries or libraries has been completed (S32).

[0051] In the example of Fig. 4, the inspection unit 21 has not yet finished checking any of the libraries libA, libB, and libC, so it executes the process of step S41 shown in Fig. 12. Fig. 12 is a diagram showing the flow of the inspection process, similar to Fig. 11.

[0052] In step S41, the checking unit 21 selects one unconfirmed library. Here, it is assumed that the checking unit 21 selects libA from among libA, libB, and libC.

[0053] Next, the inspection unit 21 determines whether libA is included in the inspected binary list (S42). The hash value of libA is acquired, and if the binary hash is not present in the inspected binary list, the inspection unit 21 determines that libA is not included in the inspected binary list. Furthermore, if the inspection unit 21 determines in step S42 that the binary or library to be inspected is included in the inspected binary list, it executes the processes from step S46 onward.

[0054] If the inspection unit 21 determines in step S42 that libA is not included in the inspected binary list, it needs to inspect libA, and therefore starts inspection processing for libA (S43). Step S43 indicates that recursive processing is performed. Specifically, step S43 is the same processing as step S24, and executes the inspection processing of FIGS. 11 and 12. In other words, step S43 indicates that the inspection unit 21 further calls the inspection processing shown in FIGS. 11 and 12 while executing the inspection processing shown in FIGS. 11 and 12. This operation may be, for example, a function that executes an inspection processing in a program, and then calls a function that executes the inspection processing.

[0055] Returning to step S31 in FIG. 11 , the inspection unit 21 extracts a set of binaries directly imported by libA, the current library to be inspected (S31_1). Here, "_1" in S31_1 indicates the process called for the first time in step S43. In the following description, "_2" indicates the process called for the second time in step S43, and "_3" indicates the process called for the third time in step S43. In the example of FIG. 4 , the inspection unit 21 extracts libC, which is directly imported by libA. Next, the inspection unit 21 determines whether confirmation of the extracted libC has been completed (S32_1). Because libC has not been confirmed up to this point, the inspection unit 21 executes the process of step S41 shown in FIG. 12 .

[0056] Next, the inspection unit 21 selects libC as an unconfirmed library (S41_1). Next, the inspection unit 21 determines whether libC is included in the inspected binary list (S42_1). Because the binary hash of libC does not exist in the inspected binary list, the inspection unit 21 determines that libC is not included in the inspected binary list.

[0057] Next, the checking unit 21 starts the checking process of libC (S43_1). That is, the checking unit 21 further calls the checking process and starts the checking process of FIG.

[0058] Returning to step S31 in Fig. 11 , the inspection unit 21 extracts a group of binaries directly imported by libC, the current library to be inspected (S31_2). In the example of Fig. 4 , the inspection unit 21 extracts libF, which is directly imported by libC. Next, the inspection unit 21 determines whether confirmation of the extracted libF has been completed (S32_2). Because confirmation of libF has not been completed, the inspection unit 21 executes the process of step S41 shown in Fig. 12 .

[0059] Next, the inspection unit 21 selects libF as an unconfirmed library (S41_2). Next, the inspection unit 21 determines whether libF is included in the inspected binary list (S42_2). Because the binary hash of libF does not exist in the inspected binary list, the inspection unit 21 determines that libF is not included in the inspected binary list.

[0060] Next, the inspection unit 21 starts the inspection process of libF (S43_2). That is, the inspection unit 21 further calls the inspection process and starts the inspection process of FIG.

[0061] Returning to step S31 in Fig. 11 , the inspection unit 21 extracts a group of binaries directly imported by libF, the current library to be inspected (S31_3). In the example of Fig. 4 , there are no libraries directly imported by libF, so the inspection unit 21 does not extract any libraries directly imported by libF in step S31. Next, the inspection unit 21 determines whether confirmation of the extracted libraries has been completed (S32_3). Because no libraries have been extracted, the inspection unit 21 determines that confirmation of all libraries has been completed, and executes the processes from step S33 onward.

[0062] In step S33, the inspection unit 21 inspects libF, which is the library to be inspected (S33_3). Here, since there is no library that libF directly imports and there is no source function list or sink function list associated with libF, the inspection unit 21 inspects libF without using the source function list or sink function list.

[0063] Next, the inspection unit 21 determines whether or not an inspection result indicating that there is no problem has been obtained after the inspection (S34_3). An inspection result indicating that there is no problem may be, for example, a result that the binary or library to be inspected does not contain any malicious function. Alternatively, the inspection unit 21 may make this determination by having the inspector check the inspection result and input information indicating that there is no problem.

[0064] If the inspection unit 21 determines that an inspection result indicating that there is no problem has been obtained, it adds the library to be inspected, i.e., libF, to the inspected binary list (S35_3). Thereafter, the inspection unit 21 ends the inspection process for libF. If the inspection unit 21 does not obtain an inspection result indicating that there is a problem, that is, if it determines that an inspection result indicating that there is a problem has been obtained, it ends the inspection process for libF without adding libF to the inspected binary list.

[0065] The inspection process for libF is the inspection process called in step S43_2. Therefore, after the inspection of libF is completed, the processes from step S44_2 onward are executed. After the inspection of libF is completed, the acquisition unit 11 determines whether the inspection result for libF is satisfactory (S44_2). If the acquisition unit 11 determines that the inspection result for libF is satisfactory, it generates a policy for libF (S46_2). Generating a policy involves generating a source function list and a sink function list.

[0066] If the acquiring unit 11 determines in step S44_2 that the inspection result for libF is problematic and if step S46_2 is executed, the acquiring unit 11 designates libF as a confirmed binary (S45_2). libF designated as a confirmed binary may be added to a confirmed binary list as shown in Fig. 13. The confirmed binary list may be managed by the managing unit 12. The confirmed binary list shown in Fig. 13 is managed by associating binary hashes with binary names.

[0067] Returning to FIG. 11, after step S45_2 is executed, the processing from step S32_2 onwards is repeated. In step S32_2, it is determined whether or not confirmation of all libraries directly imported by libC has been completed. In this case, the library directly imported by libC is libF, and confirmation of libF has been completed. Therefore, the inspection unit 21 determines that confirmation of all libraries directly imported by libC has been completed (S32_2). Thereafter, steps S33_2 to S35_2 are executed in the same manner as steps S33_3 to S35_3. Furthermore, after step S35_2 is executed, the processing from step S44_1 onwards is executed. The processing from step S44_1 onwards is the same as the processing from step S44_2 onwards, and therefore detailed description thereof will be omitted.

[0068] The recursive process is repeated, and in step S32, it is determined that libB has not yet been verified among the binaries directly imported by the binary to be inspected, so the process of step S41 in FIG. 12 is executed, and the inspection unit 21 selects libB (libC is a verified binary in step S45_1). Here, libB has already been inspected on another occasion and is included in the list of inspected binaries. In this case, the inspection unit 21 determines in step S42 that libB is included in the list of inspected binaries, and the processes from step S46 onwards are executed.

[0069] When the recursive process is repeated and the inspection process for the binary to be inspected, including libA, libB, and libC, is completed, the process from step S25 onwards in Fig. 10 is executed. By executing the processes in Fig. 10 to Fig. 12, inspection of all libraries included in the binary to be inspected is executed. Furthermore, the source function list and sink function list are created or updated using functions included in libraries that have been inspected and found to be problem-free.

[0070] Next, the detailed flow of the policy creation process in step S46 of Fig. 12 will be described with reference to Fig. 14. Policy creation includes policy update, and further includes knowledge creation and update. Fig. 14 is a diagram showing the flow of the policy creation process.

[0071] First, the acquisition unit 11 determines whether a function associated with an inspected binary or an inspected library is included in the policy (S51). Assume that the acquisition unit 11 determines that a function associated with an inspected binary or an inspected library is not included in the policy. In this case, the acquisition unit 11 adds functions included in the inspected binary or the inspected library that correspond to source functions or sink functions to a source function list or sink function list (S52). Furthermore, if a source function list or sink function list does not exist, the acquisition unit 11 adds the functions that correspond to source functions or sink functions to a newly created source function list or sink function list.

[0072] In step S51, if the obtaining unit 11 determines that the policy includes a function associated with the checked binary or the checked library, the obtaining unit 11 skips the process of step S52.

[0073] Next, the acquisition unit 11 determines whether a function associated with the inspected binary or the inspected library is included in the knowledge (S53). Assume that the acquisition unit 11 determines that a function associated with the inspected binary or the inspected library is not included in the knowledge. In this case, the acquisition unit 11 adds, to the knowledge (S54), a function that propagates data input from outside, among the functions included in the inspected binary or the inspected library. Furthermore, if no knowledge exists, the acquisition unit 11 adds, to the newly created knowledge, a function that propagates data input from outside.

[0074] In step S53, if the acquiring unit 11 determines that the knowledge includes a function associated with the checked binary or the checked library, it skips the process of step S54.

[0075] As described above, when inspecting multiple libraries included in a binary to be inspected, the inspection device 20 can avoid inspecting an already inspected library multiple times, thereby reducing the inspection time.

[0076] The inspection device 20 also accumulates policies related to binaries or libraries that have no problems in the inspection results. Therefore, when inspecting a binary or library, functions associated with the binary or library to be inspected may already be stored in the policy. In this case, by utilizing the policy when inspecting the binary or library to be inspected, the number of inspection items can be reduced. This further reduces the inspection time. The inspection items may be, for example, the processing flow to be inspected.

[0077] (Embodiment 3) Figures 15 and 16 show a flow of inspection processing different from that of Figures 11 and 12. Here, with regard to Figures 15 and 16, processing different from that of Figures 11 and 12 will be mainly described, and detailed description of processing similar to that of Figures 11 and 12 will be omitted.

[0078] Steps S61 and S62 in Fig. 15 are similar to steps S31 and S32 in Fig. 11, and therefore detailed description thereof will be omitted. Next, in step S62, if the inspection unit 21 determines that confirmation of all extracted binaries or libraries has not been completed, processing from step S71 onwards is executed. Steps S71, S72, S73 and S74 are similar to steps S41, S42, S43 and S45 in Fig. 12, and therefore detailed description thereof will be omitted.

[0079] However, if the inspection unit 21 determines in step S72 that the selected unconfirmed library is included in the inspected binary list, the process of step S74 is executed without executing the policy creation process of step S46. Furthermore, after the inspection process of step S73 is completed, the process of step S74 is executed without executing the process of step S44 to determine whether or not there is a problem with the inspection result.

[0080] If the inspection unit 21 determines in step S62 that all extracted binaries or libraries have been checked, the same policy creation process as in step S46 of Fig. 12 is executed (S63). However, in steps S51 and S53 of Fig. 14, functions associated with inspected binaries (libraries) are processed as functions associated with the currently targeted inspection target binary (library). Next, the inspection unit 21 inspects the inspection target binary (S64).

[0081] In the inspection of step S64, the inspection unit 21 performs the inspection using the policy created in step S63. That is, the inspection unit 21 identifies or extracts a processing flow using the source function list and the sink function list. Furthermore, the inspection unit 21 inspects the binary to be inspected by analyzing the processing flow.

[0082] Steps S65 and S66 are similar to steps S34 and S35 in Fig. 11, and therefore detailed description thereof will be omitted. If the inspection result in step S65 indicates a problem, the acquisition unit 11 discards the policy created in step S63 (S67).

[0083] As described above, before the inspection device 20 performs inspection of the binary to be inspected, the acquisition unit 11 generates a policy including a source function list and a sink function list. The inspection device 20 then performs inspection by analyzing the process flow between the source functions and sink functions identified using the policy. By analyzing the process flow based on the policy, the number of analyses to determine whether a function is a source function or a sink function and the number of process flows to be analyzed can be reduced compared to when all functions included in the binary are first determined to be source functions or sink functions and then inspected. As a result, the inspection device 20 can shorten the inspection time compared to when a policy is not created before inspection.

[0084] FIG. 17 is a block diagram showing an example configuration of the inspection device 10 and the inspection device 20 (hereinafter referred to as the inspection device 10, etc.). Referring to FIG. 17, the inspection device 10, etc. includes a network interface 1201, a processor 1202, and a memory 1203. The network interface 1201 may be used to communicate with a network node. The network interface 1201 may include, for example, a network interface card (NIC) conforming to the IEEE 802.3 series. IEEE stands for Institute of Electrical and Electronics Engineers.

[0085] The processor 1202 reads and executes software (computer programs) from the memory 1203 to perform the processing of the core network node 10 and the like described using the flowcharts. The processor 1202 may be, for example, a microprocessor, an MPU, or a CPU. The processor 1202 may include multiple processors.

[0086] The memory 1203 is configured by a combination of volatile memory and non-volatile memory. The memory 1203 may include storage located remotely from the processor 1202. In this case, the processor 1202 may access the memory 1203 via an I / O (Input / Output) interface (not shown).

[0087] 17, the memory 1203 is used to store a group of software modules. The processor 1202 can perform processing of the inspection device 10, etc., by reading and executing the group of software modules from the memory 1203.

[0088] As explained using FIG. 17, each of the processors possessed by the inspection device 10, etc., executes one or more programs including a group of instructions for causing a computer to perform the algorithm explained using the drawings.

[0089] In the above examples, the program includes instructions (or software code) that, when loaded into a computer, cause the computer to perform one or more functions described in the embodiments. The program may be stored on a non-transitory computer-readable medium or a tangible storage medium. By way of example and not limitation, computer-readable medium or tangible storage medium includes random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disc (DVD), Blu-ray disc or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The program may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable medium or communication medium includes electrical, optical, acoustic, or other forms of propagated signals.

[0090] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above-described embodiments. Various modifications that can be understood by those skilled in the art can be made to the configuration and details of the present disclosure within the scope of the present disclosure. Furthermore, each embodiment can be combined with other embodiments as appropriate.

[0091] Each drawing is merely an example for describing one or more embodiments. Each drawing may not relate to only one particular embodiment, but may also relate to one or more other embodiments. As will be understood by those skilled in the art, various features or steps described with reference to any one drawing can be combined with features or steps shown in one or more other drawings to create, for example, an embodiment not explicitly shown or described. Not all features or steps shown in any one drawing are necessary to describe an exemplary embodiment, and some features or steps may be omitted. The order of steps described in any drawing may be changed as appropriate.

[0092] Some or all of the above embodiments can be described as, but are not limited to, the following supplementary notes. (Supplementary Note 1) An inspection device comprising: an acquisition unit that acquires management information in which software identification information is associated with a list of a function that is a start point of inspection and a function that is an end point of inspection, the function being included in the software; and a management unit that manages the management information, wherein the management unit manages the identification information of the software to be inspected associated with the list as inspected software after inspection of the software to be inspected is completed. (Supplementary Note 2) The inspection device according to Supplementary Note 1, wherein the management unit manages the management information associated with the software to be inspected when it is determined in the inspection of the software to be inspected that there is no security problem. (Supplementary Note 3) The inspection device according to Supplementary Note 1 or 2, wherein the management unit manages the management information created after inspection of the software to be inspected is completed. (Supplementary Note 4) The inspection device according to Supplementary Note 1 or 2, wherein the management unit manages the management information created before inspection of the software to be inspected is started. (Supplementary Note 5) The inspection device according to Supplementary Note 4, wherein the management unit discards the management information if a security problem is determined in the inspection of the software to be inspected. (Supplementary Note 6) The inspection device according to any one of Supplements 1 to 5, wherein the management unit manages first management information that associates identification information of at least one sub-software imported into the software to be inspected with a list of functions included in the sub-software that serve as a starting point for the inspection and a list of functions that serve as an end point for the inspection. (Supplementary Note 7) The inspection device according to any one of Supplements 1 to 6, wherein the functions that serve as the starting point and the end point for the inspection are functions that execute a system call instruction. (Supplementary Note 8) The inspection device according to any one of Supplements 1 to 7, further comprising an inspection unit that avoids inspection of the software to be inspected if the software to be inspected is managed as the inspected software.(Supplementary Note 9) A management method comprising: acquiring management information associating software identification information with a list of functions included in the software that are the start point of the inspection and a list of functions that are the end point of the inspection; storing the management information; and managing the identification information of the software to be inspected that is associated with the list as inspected software after inspection of the software to be inspected is completed. (Supplementary Note 10) The management method according to Supplementary Note 9, wherein, when managing the management information, if it is determined in the inspection of the software to be inspected that there is no security problem, the management information associated with the software to be inspected is managed. (Supplementary Note 11) The management method according to Supplementary Note 9 or 10, wherein, when managing the management information, the management information created after the inspection of the software to be inspected is completed is managed. (Supplementary Note 12) The management method according to Supplementary Note 9 or 10, wherein, when managing the management information, the management information created before the inspection of the software to be inspected is started is managed. (Supplementary Note 13) The management method according to Supplementary Note 12, wherein, when managing the management information, if it is determined in the inspection of the software to be inspected that there is a security problem, the management information is discarded. (Supplementary Note 14) The management method according to any one of Supplements 9 to 13, wherein, when managing the management information, first management information is managed in which identification information of at least one subsoftware imported into the software to be inspected is associated with a list of functions included in the subsoftware that serve as a starting point for inspection and a list of functions that serve as an end point for inspection. (Supplementary Note 15) The management method according to any one of Supplements 9 to 14, wherein the functions that serve as the starting point and the end point for inspection are functions that execute a system call instruction. (Supplementary Note 16) The management method according to any one of Supplements 9 to 15, wherein, if the software to be inspected is managed as the inspected software, inspection of the software to be inspected is avoided.(Supplementary Note 17) A program that causes a computer to acquire management information that associates software identification information with a list of functions included in the software that are the start point of an inspection and a list of functions that are the end point of the inspection, manages the management information, and after inspection of the software to be inspected is completed, manages the identification information of the software to be inspected that is associated with the list as inspected software. (Supplementary Note 18) The program according to Supplementary Note 17, which, when managing the management information, manages the management information associated with the software to be inspected if it is determined in the inspection of the software to be inspected that there are no security issues. (Supplementary Note 19) The program according to Supplementary Note 17 or 18, which, when managing the management information, manages the management information created after inspection of the software to be inspected has ended. (Supplementary Note 20) The program according to Supplementary Note 17 or 18, which, when managing the management information, manages the management information that was created before inspection of the software to be inspected was started.

[0093] Some or all of the elements (e.g., configurations and functions) described in Supplementary Notes 2 to 8 that are dependent on Supplementary Note 1 may also be dependent on Supplementary Notes 9 and 17 in the same dependency relationship as Supplementary Notes 2 to 8. Some or all of the elements described in any Supplementary Note may be applied to various hardware, software, recording means for recording software, systems, and methods.

[0094] 10 Inspection device 11 Acquisition unit 12 Management unit 20 Inspection device 21 Inspection unit 1201 Network interface 1202 Processor 1203 Memory

Claims

1. An inspection device comprising: an acquisition unit that acquires management information that associates software identification information with a list of functions that are the starting point of the inspection and functions that are the end point of the inspection, which are included in the software; and a management unit that manages the management information, wherein after inspection of the software to be inspected is completed, the management unit manages the identification information of the software to be inspected that is associated with the list as inspected software.

2. The inspection device according to claim 1, wherein the management unit manages the management information associated with the software to be inspected when it is determined that there are no security issues during the inspection of the software to be inspected.

3. The inspection device according to claim 1 or 2, wherein the management unit manages the management information created after the inspection of the software to be inspected is completed.

4. An inspection device as described in claim 1 or 2, wherein the management unit manages the management information created before inspection of the software to be inspected is started.

5. The inspection device according to claim 4, wherein the management unit discards the management information if a security problem is determined to exist during the inspection of the software to be inspected.

6. An inspection device described in any one of claims 1 to 5, wherein the management unit manages first management information that associates identification information of at least one sub-software imported into the software to be inspected with a list of functions included in the sub-software that are the starting point of the inspection and a list of functions that are the end point of the inspection.

7. The inspection device according to any one of claims 1 to 6, wherein the function that is the start point and the function that is the end point of the inspection are functions that execute a system call instruction.

8. The inspection device according to any one of claims 1 to 7, further comprising an inspection unit that avoids inspection of the software to be inspected when the software to be inspected is managed as the inspected software.

9. A management method comprising: acquiring management information that associates software identification information with a list of functions included in the software that are the starting point of the inspection and a list of functions that are the end point of the inspection; managing the management information; and, after the inspection of the software to be inspected is completed, managing the identification information of the software to be inspected that is associated with the list as inspected software.

10. A management method as described in claim 9, wherein when managing the management information, if an inspection of the software to be inspected determines that there are no security issues, the management information associated with the software to be inspected is managed.

11. A management method according to claim 9 or 10, wherein when managing the management information, the management information created after the inspection of the software to be inspected is completed is managed.

12. A management method according to claim 9 or 10, wherein when managing the management information, the management information created before the start of inspection of the software to be inspected is managed.

13. The management method according to claim 12, wherein, when managing the management information, if an inspection of the software to be inspected determines that there is a security problem, the management information is discarded.

14. A management method according to any one of claims 9 to 13, wherein when managing the management information, first management information is managed that associates identification information of at least one sub-software imported into the software to be inspected with a list of functions included in the sub-software that are the starting point of the inspection and a list of functions that are the end point of the inspection.

15. The management method according to any one of claims 9 to 14, wherein the function that is the start point and the function that is the end point of the inspection are functions that execute a system call instruction.

16. The management method according to any one of claims 9 to 15, wherein inspection of the software to be inspected is avoided if the software to be inspected is managed as the inspected software.

17. A program that causes a computer to acquire management information that associates software identification information with a list of functions that are the starting point of an inspection and functions that are the end point of an inspection contained in the software, manages the management information, and, after inspection of the software to be inspected is completed, manages the identification information of the software to be inspected that is associated with the list as inspected software.

18. The program described in claim 17, wherein, when managing the management information, if an inspection of the software to be inspected determines that there are no security issues, the program manages the management information associated with the software to be inspected.

19. A program according to claim 17 or 18, wherein when managing the management information, the management information created after the inspection of the software to be inspected is completed is managed.

20. A program as claimed in claim 17 or 18, wherein when managing the management information, the management information created before the start of inspection of the software to be inspected is managed.

Images