Information processing device, information processing method, and information processing program

Abstract

To appropriately evaluate the impact when vulnerability of an inspection target is attacked even in environments where it is impossible to directly access the inspection target.SOLUTION: An information processing device 10 comprises an extraction unit 20A and a registration unit 20B. The extraction unit 20A extracts first file path information representing a file path in an inspection target 30 of a file used for vulnerability inspection of the inspection target 30 by a vulnerability inspection tool 50A. The registration unit 20B registers second file path information representing the file path to the file copied from the inspection target 30 using the first file path information in second management information 16C in association with the first file path information.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] An embodiment of the present invention relates to an information processing device, an information processing method, and an information processing program. [Background technology]

[0002] Numerous new vulnerabilities are reported every day, and based on vulnerability information provided by vendors and others, the impact of attacks on various computer-based systems and other target systems is assessed. Impact assessment involves determining whether the conditions for vulnerability occurrence indicated in the vulnerability information provided match the target system, and if so, assessing the risk. In addition, vulnerability testing tools are used to test the target system for vulnerabilities, automatically determining whether the conditions match the vast amount of vulnerability information provided daily and testing the target system for vulnerabilities.

[0003] There are cases where a vulnerability testing tool cannot directly access a test target due to shipping of the test target, etc. Therefore, a method has been disclosed in which a digital twin is created by copying all of the information contained in the test target, and the digital twin is then tested using a vulnerability testing tool. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2009-217637 [Patent Document 2] Japanese Patent Application Laid-Open No. 2015-138509 Summary of the Invention [Problem to be solved by the invention]

[0005] However, generating digital twins for each of a huge number of inspection targets would require a huge amount of data to be stored, making it impractical.However, with conventional technology, it has been difficult to properly evaluate the impact of an attack on a vulnerability in an inspection target in an environment where direct access to the inspection target is not possible.

[0006] The problem that the present invention aims to solve is to provide an information processing device, an information processing method, and an information processing program that can appropriately evaluate the impact when a vulnerability in an object to be inspected is attacked, even in an environment where the object to be inspected cannot be directly accessed. [Means for solving the problem]

[0007] According to an embodiment, an information processing apparatus includes an extracting unit and a registering unit. The extracting unit extracts first file path information representing a file path in an inspection target of a file used in a vulnerability test of the inspection target by a vulnerability testing tool. The registering unit associates the first file path information with second file path information representing a file path to a file copied from the inspection target using the first file path information, and registers the first file path information in second management information. [Brief explanation of the drawings]

[0008] [Figure 1] FIG. 1 is a functional block diagram of an information processing system. [Figure 2A] 10 is a schematic diagram of the data structure of vulnerability testing method information. [Figure 2B] 10 is a schematic diagram of the data structure of vulnerability testing method information. [Figure 3] An explanatory diagram of the OVAL structure. [Figure 4] FIG. 4 is a schematic diagram of the data structure of first management information. [Figure 5] FIG. 4 is a schematic diagram of the data structure of second management information. [Figure 6] 1 is a flowchart of the flow of information processing executed by an information processing device. [Figure 7] 10 is a flowchart of the flow of extraction processing by an extraction unit. [Figure 8]FIG. 1 is a functional block diagram of an information processing system. [Figure 9] 1 is a flowchart of the flow of information processing executed by an information processing device. [Figure 10] FIG. 2 is a diagram illustrating a hardware configuration. DETAILED DESCRIPTION OF THE INVENTION

[0009] The information processing device, the information processing method, and the information processing program according to the present embodiment will be described in detail below with reference to the accompanying drawings.

[0010] In the following description of each embodiment, parts denoted by the same reference numerals have substantially the same functions, and descriptions of overlapping parts will be omitted where appropriate.

[0011] (First embodiment) FIG. 1 is a functional block diagram of an example of an information processing system 1 according to the present embodiment.

[0012] The information processing system 1 includes an information processing device 10, an inspection object 30, and an inspection device 40. The information processing device 10 and the inspection object 30 can be connected to each other so as to be able to communicate with each other directly or via a network or the like. The information processing device 10 and the inspection device 40 can be connected to each other so as to be able to communicate with each other directly or via a network or the like.

[0013] The inspection target 30 is a system whose vulnerabilities are to be evaluated. The inspection target 30 includes one or more computers. The computers are equipped with software such as an OS (Operating System), OSS (Open Source Software), and App (Application program or Application software). Examples of OS and OSS include, but are not limited to, Linux (registered trademark), Unix (registered trademark), Windows (registered trademark), Android (registered trademark), iOS (registered trademark), etc. These software programs operate by using or including one or more software components. Software components may be referred to as drivers, services, libraries, etc. For example, Linux operates by using or including the kernel functions of the OS itself and software components such as numerous device drivers and services.

[0014] The inspection device 40 is an information processing device for executing vulnerability inspection on the inspection target 30 .

[0015] The inspection device 40 includes a communication unit 42, a UI (user interface) unit 44, a storage unit 46, and a processing unit 50. The communication unit 42, the UI unit 44, the storage unit 46, and the processing unit 50 are communicatively connected via a bus 48 or the like.

[0016] The communication unit 42 communicates with the information processing device 10 directly or via a network or the like. The UI unit 44 has a display function for displaying various information and an input function for receiving operation instructions from the user. The display function is a display for displaying various information. The input function is, for example, a pointing device such as a mouse, a keyboard, etc. The storage unit 46 stores various information.

[0017] The processing unit 50 executes information processing in the inspection device 40. The processing unit 50 has a vulnerability inspection tool 50A. The vulnerability inspection tool 50A is realized by one or more processors. For example, the vulnerability inspection tool 50A may be realized by having a processor such as a CPU (Central Processing Unit) execute a program, i.e., by software. The vulnerability inspection tool 50A may also be realized by a processor such as a dedicated IC, i.e., by hardware. The vulnerability inspection tool 50A may also be realized by using a combination of software and hardware. The vulnerability inspection tool 50A may also be installed in the information processing device 10.

[0018] The vulnerability inspection tool 50A is a tool that executes a vulnerability inspection of the inspection target 30 based on the vulnerability information.

[0019] Vulnerability information is information that indicates a vulnerability. Vulnerability information includes information related to the vulnerability. Specifically, for example, vulnerability information includes information that indicates compatibility conditions that match the vulnerability, evaluation criteria including risk values ​​for each of the compatibility conditions, the expected extent of the impact that the vulnerability will have on the inspection target 30, and countermeasures to address the vulnerability. Vulnerability information is provided by CVE (Common Vulnerabilities and Exposures), NVD (National Vulnerability Database), JVN (Japan Vulnerability Notes), etc.

[0020] Vulnerability information is provided not only in normal text format but also in a security testing language that can be processed by machines. In this embodiment, vulnerability information is described in OVAL (Open Vulnerability and Assessment Language), which is an example of a security testing language.

[0021] The vulnerability testing tool 50A performs a compatibility determination as to whether the compatibility conditions of the vulnerability information are compatible with the test target 30, evaluates the risk if they are compatible, and if the risk is high, applies a patch provided by the software vendor or takes a workaround, etc. Through these processes, the vulnerability testing tool 50A performs a vulnerability test on the test target 30.

[0022] The vulnerability compatibility determination uses not only package information of the installed software included in the inspection target 30, but also the contents of files such as configuration files. Security inspection languages ​​such as OVAL allow compatibility conditions to be written using file paths and values. If the inspection target 30 is directly accessible, the vulnerability inspection tool 50A determines vulnerability compatibility by checking the package information and file contents of the inspection target 30. Examples of vulnerability inspection tools 50A include Vuls (VULnerability Scanner).

[0023] The information processing device 10 includes a communication unit 12, a UI unit 14, a storage unit 16, and a processing unit 20. The communication unit 12, the UI unit 14, the storage unit 16, and the processing unit 20 are communicatively connected via a bus 18 or the like.

[0024] The communication unit 12 communicates with each of the inspection object 30 and the inspection device 40 directly or via a network or the like. The UI unit 14 includes a display unit 14A and an input unit 14B. The display unit 14A is a display that displays various information. The input unit 14B accepts operation instructions from a user. The input unit 14B is, for example, a pointing device such as a mouse, a keyboard, etc. The memory unit 16 stores various information. The memory unit 16 may be a storage device provided outside the information processing device 10. For example, the memory unit 16 may be installed in an external information processing device connected to the information processing device 10 via a network or the like.

[0025] In this embodiment, the storage unit 16 stores various types of information such as vulnerability testing method information 16A, first management information 16B, second management information 16C, a file storage unit 16D, and a virtual file system 16E. Details of these pieces of information will be described later.

[0026] The processing unit 20 includes an extraction unit 20A, a registration unit 20B, and a construction unit 20C. The extraction unit 20A, the registration unit 20B, and the construction unit 20C are realized, for example, by one or more processors. For example, each of the above units may be realized by having a processor such as a CPU (Central Processing Unit) execute a program, i.e., by software. Each of the above units may be realized by a processor such as a dedicated IC, i.e., by hardware. Each of the above units may be realized by a combination of software and hardware. When multiple processors are used, each processor may realize one of the units, or may realize two or more of the units. Furthermore, at least one of the above units may be provided in an external information processing device connected to the information processing device 10 via a network.

[0027] As described above, when the vulnerability testing tool 50A can directly access the inspection target 30, the vulnerability testing tool 50A checks the package information and file contents of the inspection target 30 to determine whether the vulnerability is compatible with the inspection target 30. However, when the inspection target 30 is shipped or otherwise placed in an environment where the vulnerability testing tool 50A cannot directly access the inspection target 30, the vulnerability testing tool 50A cannot directly test the inspection target 30. Another method involves creating a digital twin that copies all of the information contained in the inspection target 30 and then using the vulnerability testing tool 50A to detect vulnerabilities on the digital twin. However, creating a digital twin for each of the enormous number of inspection targets 30 requires enormous amounts of data to store, making it impractical. With conventional technology, in an environment where the vulnerability testing tool 50A cannot directly access the inspection target 30, it was difficult to appropriately evaluate the impact of an attack on a vulnerability in the inspection target 30.

[0028] Therefore, the processing unit 20 of this embodiment includes at least an extraction unit 20A and a registration unit 20B. The processing unit 20 may further include a construction unit 20C.

[0029] The extraction unit 20A extracts first file path information that indicates the file path of a file used by the vulnerability testing tool 50A to test for vulnerability of the test target 30. The file path is information that indicates the location or storage location of a specific file within a computer.

[0030] The first file path information is information that indicates a file path in the inspection target 30 to a file that is used for vulnerability inspection of the inspection target 30.

[0031] The extraction unit 20A extracts the first file path information based on the vulnerability testing method information 16A.

[0032] The vulnerability testing method information 16A is information that defines a method for the vulnerability testing tool 50A to test for vulnerabilities in the test target 30. The vulnerability testing method information 16A is written in the same security testing language as the vulnerability information. In this embodiment, the vulnerability testing method information 16A will be described assuming that it is written in OVAL, similar to the vulnerability information.

[0033] 2A and 2B are schematic diagrams showing an example of the data configuration of the vulnerability testing method information 16A.

[0034] 2A and 2B show an example of vulnerability testing method information 16A configured from vulnerability testing method information 16A1 shown in Fig. 2A and vulnerability testing method information 16A2 shown in Fig. 2B. 2A and 2B show an example of vulnerability testing method information 16A as an OVAL file written in XML (Extensible Markup Language). Note that an actual OVAL file contains XML namespace information, but this information is omitted from the examples shown in Fig. 2A and 2B to avoid complication.

[0035] The vulnerability testing method information 16A includes OVAL file information, vulnerability information, a test definition, a test target, a test target, and a state of the test target.

[0036] The OVAL file information is bibliographic information of the vulnerability testing method information 16A. The test definition is information that represents the definition of the vulnerability testing. The test target is information that represents the target, such as a file, used in the vulnerability testing. The test target state is information that represents the state that must be met for the file, etc. used in the vulnerability testing.

[0037] Specifically, for example, the vulnerability testing method information 16A includes the following elements under "oval_definitions," which is the root element of the OVAL file:

[0038] generator: Represents the bibliographic information of the vulnerability testing method information 16A, and corresponds to the above-mentioned OVAL file information. The bibliographic information represents, for example, the title, version, creation date, etc. definitions: Represents a set of vulnerability information. Directly under definitions there are multiple definition elements that represent individual vulnerability information. tests: Represents a set of test conditions that describe the compatibility conditions for vulnerability information. Directly below tests are elements that describe individual test conditions. A test definition is represented by a set of test conditions. objects: Represents a set of test condition targets. Directly under objects are elements that describe each target. states: Represents a set of conditions (values) that the test subject must satisfy. Directly under objects are elements that describe individual conditions. The set of conditions represents the state of the test subject.

[0039] A definition element corresponds to one piece of vulnerability information and consists of a metadata element that represents the contents of the vulnerability information, such as a description of the vulnerability and the level of risk, and a criteria element that represents the vulnerability's matching conditions. The vulnerability's matching conditions are expressed as a logical expression of multiple conditions, and the criterion elements that represent individual conditions express the logical expression using the operator attribute value (e.g., "AND") of the criteria element above them. The criterion element has a test_ref attribute. The test_ref attribute points to the element that has the test_ref attribute value as its ID among the elements directly under the tests element.

[0040] An element under the tests element (for example, "textfilecontent54_test") has an object element that represents the test target and a state element that represents the condition that the target must satisfy. The object element has an object_ref attribute. The object_ref attribute points to an element that has the attribute value of object_ref as its ID among the elements directly under the objects element. The state element also has an object_ref attribute. The state element points to an element that has the attribute value of states_ref as its ID among the elements directly under the states element (see Figure 3). Figure 3 is an explanatory diagram of an example of the structure of OVAL. Figure 3 also shows an example of the relationship between elements that have the above attribute values ​​as their ID. Let's return to Figures 2A and 2B to continue the explanation.

[0041] The test conditions are defined by the element names under the tests element. An example is shown below.

[0042] rpminfo_test: Indicates that the target software is to be tested to see if it is included in the Linux software package management system rpm. The object element indicates the package name, and the state element describes the conditions related to the software version. textfilecontent54_test: Tests whether a specified file contains a specific string. The object element identifies the file, and the state element specifies the condition for the string contained in the file. xinetd_test: This indicates that the xinetd configuration file that configures the network is examined and the configuration contents are tested. The object element specifies the name of the configuration item, and the state element specifies the condition that the configuration value must meet.

[0043] Returning to Figure 1, we continue the explanation.

[0044] Based on the vulnerability testing method information 16A, the extraction unit 20A extracts first file path information that indicates file paths in the test target 30 of files included in the test target 30 and that are used in vulnerability testing of the test target 30 by the vulnerability testing tool 50A. That is, the extraction unit 20A reads the vulnerability testing method information 16A, obtains individual compatibility conditions for vulnerabilities for each piece of vulnerability information defined in the vulnerability testing method information 16A, and reads element values ​​for each compatibility condition from the vulnerability testing method information 16A. Through this reading process, the extraction unit 20A extracts, as the first file path information, file paths in the test target 30 of files included in the test target 30 and that are used in vulnerability testing by the vulnerability testing tool 50A.

[0045] Specifically, for example, the extraction unit 20A reads the vulnerability testing method information 16A and acquires one definition element included in the vulnerability testing method information 16A to acquire one piece of vulnerability information. Then, each time the extraction unit 20A acquires one piece of vulnerability information, it acquires the matching condition represented by the vulnerability information. For example, the extraction unit 20A acquires the criteria element immediately under the definition element to acquire the matching condition.

[0046] Then, each time the extraction unit 20A acquires one matching condition by acquiring one criteria element, it extracts the element immediately below the tests element that has the same ID as the attribute of test_ref included in the matching condition.

[0047] For example, assume that the extracted element has the element name "textfilecontent54_test," which represents an element that represents a test target and a condition that the target must satisfy. In this case, the extraction unit 20A extracts an element that is included in the element with the element name "textfilecontent54_test," is directly under the object element that represents the test target, and whose ID matches the attribute value of object_ref. Then, the extraction unit 20A extracts the value of the "filepath" element included in the extracted element as the first file path information.

[0048] Furthermore, if the element name of the extracted element is "xinetd_test," which indicates that the configuration file of xinetd, which configures the network, is examined and the configuration contents are tested, the extraction unit 20A extracts the same file path (for example, " / etc / xinted.conf") as the first file path information regardless of the object element.

[0049] Then, the extraction section 20A registers the extracted first file path information in the first management information 16B.

[0050] 4 is a schematic diagram showing an example of the data configuration of the first management information 16 B. The first management information 16 B has a plurality of records that associate types with values.

[0051] The extraction unit 20A associates the extracted first file path information with the type of file stored in the location indicated by the file path represented by the first file path information and registers them. That is, the extraction unit 20A registers the first file path information, which is the file path in the inspection target 30 of the file used for vulnerability testing, in the "value" field of the first management information 16B, and registers "file" in the "type" field corresponding to the "value." The first management information 16B may further store a record in which a "command" is associated with the "type" field and a "command required for vulnerability testing" is associated with the "value" field corresponding to the "command" (details will be described later).

[0052] Returning to Figure 1, we continue the explanation.

[0053] The registration unit 20B associates second file path information, which indicates a file path to a file copied from the inspection target 30 using the first file path information, with the first file path information and registers the second file path information in the second management information 16C.

[0054] In detail, the registration unit 20B uses the first file path information to store the file copied from the inspection target 30 in the file storage unit 16D. That is, the registration unit 20B uses the first file path information registered in the first management information 16B to read the file stored in the location in the inspection target 30 that is indicated by the file path represented by the first file path information, and copies the file to the file storage unit 16D.

[0055] Then, the registration unit 20B associates the second file path information representing the file path to the file copied to the file memory unit 16D with the first file path information used when copying the file from the inspection target 30 and registers them in the second management information 16C.

[0056] 5 is a schematic diagram of an example of the data configuration of second management information 16C. As shown in FIG. 5, second management information 16C is information that associates first file path information with second file path information. In second management information 16C, the first file path information registered in first management information 16B is registered, and the second file path information of a file copied to file storage unit 16D by registration unit 20B is registered in association with the first file path information. In other words, in second management information 16C, for the same file, first file path information representing a file path in inspection target 30 and second file path information representing a file path in file storage unit 16D are registered in association with each other.

[0057] Returning to FIG. 1, the explanation will be continued. Next, the construction unit 20C will be explained. The processing unit 20 may or may not be provided with the construction unit 20C. In this embodiment, an example in which the processing unit 20 includes the construction unit 20C will be explained.

[0058] The construction unit 20C constructs a virtual file system 16E that associates first file path information registered in the second management information 16C with a file stored at a location indicated by a file path represented by second file path information that is associated with the first file path information in the second management information 16C.

[0059] The vulnerability testing tool 50A evaluates the impact of an attack on a vulnerability in the test target 30, for example, by using a file stored in a location indicated by a file path represented by the first file path information shown in the vulnerability information described in OVAL.

[0060] In this embodiment, the vulnerability testing tool 50A accesses a file using the second management information 16C and performs a vulnerability test. In detail, when determining compliance with a vulnerability indicated in the vulnerability information, the vulnerability testing tool 50A uses a file stored in a location in the file storage unit 16D indicated by a file path indicated by second file path information associated with the first file path information in the second management information 16C, instead of a location in the test target 30 indicated by a file path indicated by first file path information in the test target 30.

[0061] Therefore, in the information processing device 10 of this embodiment, even in an environment where the vulnerability testing tool 50A cannot directly access the test target 30, the impact of an attack on the vulnerability of the test target 30 can be appropriately evaluated.

[0062] Depending on the vulnerability testing tool 50A, the configuration may make it difficult to access a file stored in a location in the file storage unit 16D indicated by a file path represented by the second file path information associated with the first file path information in the second management information 16C.

[0063] However, as described above, in the information processing device 10, the construction unit 20C constructs the virtual file system 16E.

[0064] Therefore, even if the vulnerability testing tool 50A is configured to have difficulty accessing files stored in the file memory unit 16D, by using the virtual file system 16E and the files associated with the first file path information, it is possible to properly evaluate the impact of an attack on the vulnerability of the test target 30.

[0065] It should be noted that the extraction process of the first file path information by the extraction unit 20A, the registration process of associating the first file path information with the second file information by the registration unit 20B and registering them in the second management information 16C, the construction process of the virtual file system 16E by the construction unit 20C, and the vulnerability inspection by the vulnerability inspection tool 50A do not need to be performed consecutively in this order, and each process may be performed at the required timing.

[0066] For example, the extraction unit 20A may execute the extraction process when vulnerability information is updated or new vulnerability information is reported. The registration unit 20B may execute the registration process when the first management information 16B is updated or when the inspection target 30 is updated. The vulnerability inspection tool 50A may execute the vulnerability inspection using the second management information 16C or the virtual file system 16E when an inspection is instructed by a user operating the UI unit 44.

[0067] Next, an example of the flow of information processing executed by the information processing device 10 of this embodiment will be described.

[0068] FIG. 6 is a flowchart showing an example of the flow of information processing executed by the information processing device 10 of this embodiment.

[0069] The extraction unit 20A executes an extraction process to extract first file path information that indicates the file path of a file used in vulnerability testing of the test target 30 by the vulnerability testing tool 50A (step S100).

[0070] The registration unit 20B uses the first file path information extracted in step S100 and registered in the first management information 16B to copy and store the file from the inspection target 30 to the file storage unit 16D (step S102).

[0071] The registration unit 20B associates the second file path information representing the file path to the file stored in the file storage unit 16D in step S102 with the first file path information used when copying the file from the inspection target 30, and registers them in the second management information 16C (step S104). Then, this routine ends.

[0072] Next, a detailed example of the flow of extraction processing by the extraction unit 20A will be described.

[0073] Fig. 7 is a flowchart showing an example of the flow of extraction processing by extraction unit 20A. Fig. 7 is a flowchart showing an example of the detailed processing flow of step S100 in Fig. 6. Fig. 7 shows an example of a case where extraction unit 20A executes extraction processing to extract first file path information using vulnerability testing method information 16A shown in Figs. 2A and 2B.

[0074] First, the extraction unit 20A reads multiple pieces of vulnerability information written in OVAL recorded in the vulnerability testing method information 16A and parses the XML (step S200). The extraction unit 20A may perform the process of step S200 by using the vulnerability information actually used by the vulnerability testing tool 50A, or may perform the process of step S200 by using the latest vulnerability information published in the OVAL repository.

[0075] Then, the extraction unit 20A acquires one unprocessed "definition" element from the multiple pieces of vulnerability information read in step S200 (step S202). There are multiple "definition" elements in the vulnerability testing method information 16A read in step S200. Therefore, if the extraction unit 20A is unable to acquire an unprocessed "definition" element, that is, if the processing (i.e., acquisition) of all "definition" elements included in the vulnerability testing method information 16A read in step S200 has been completed (step S202: failure), the extraction unit 20A terminates this routine.

[0076] When the extraction unit 20A acquires one unprocessed "definition" element (step S202: success), the extraction unit 20A proceeds to step S204. In step S204, the extraction unit 20A acquires a "criteria" element immediately below the "definition" element acquired in step S202 (step S204). Then, the extraction unit 20A acquires one unprocessed "criterion" element immediately below the "criteria" element acquired in step S204 (step S206: success), and proceeds to step S208. If the extraction unit 20A has already processed all of the "criterion" elements immediately below the "criteria" element acquired in step S204, that is, if the extraction unit 20A was unable to acquire any unprocessed "criterion" elements (step S206: failure), the extraction unit 20A returns to step S202.

[0077] In step S208, the extraction unit 20A checks the value of the "test_ref" attribute of the "criterion" element (for example, com.xxx:tst:20191992001), and searches for elements directly under the "tests" element that have the same value as the "test_ref" attribute value as the "id" attribute value (step S208).

[0078] In step S210, extraction unit 20A checks the element name of the element found in step S208, and if the element name is "textfilecontent54_test", the process proceeds to step S212. If the element name is "xinetd_test", the process proceeds to step S216. If the element name is other than these, the process proceeds to step S206.

[0079] Note that the flowchart shown in Figure 7 shows an example in which the extraction unit 20A extracts the first file path information for the element name "textfilecontent54_test" and the element name "xinetd_test", but it can be extended to other test items that handle files.

[0080] In step S212, extraction unit 20A searches for an element immediately below the "objects" element that has the same values ​​as the "object_ref" attribute value and the "id" attribute value of the element with element name "textfilecontent54_test" (step S212). Then, extraction unit 20A sets the value of the "filepath" element immediately below the element searched for in step S212 as first file path information, associates it with the type "file," and registers it in first management information 16B (step S214). Then, processing proceeds to step S206.

[0081] Meanwhile, in step S216, extraction unit 20A registers the file path " / etc / xinted.conf" as the first file path information in first management information 16B in association with the type "file" (step S216). In the case of a test with the element name "xinetd_test", the configuration file to be referenced is determined to be " / etc / xinted.conf", so in step S216 extraction unit 20A registers this file path as the first file path information in first management information 16B regardless of the object element.

[0082] An example of the operation of the embodiment configured as above will be described using a specific example.

[0083] It is assumed that the vulnerability testing method information 16A1 and the vulnerability testing method information 16A2 shown in FIGS. 2A and 2B are stored in the storage unit 16 as the vulnerability testing method information 16A.

[0084] In this case, the extraction unit 20A first extracts the file path of the file used in the vulnerability test as the first file path information, as described using the flowchart in Fig. 7. In detail, the extraction unit 20A parses the vulnerability test method information 16A shown in Fig. 2A and Fig. 2B in the process of step S200.

[0085] Then, in step S202, the extraction unit 20A extracts the "definition" element shown in the line numbered 10-27 in the vulnerability testing method information 16A (corresponding to step S202: success). The numbers added to the left end of each line constituting the vulnerability testing method information 16A shown in Figures 2A and 2B indicate the line number.

[0086] Then, the extraction unit 20A proceeds to step S204, extracts the "criteria" element shown in the lines numbered 23-27 in the vulnerability testing method information 16A, and further extracts the "criterion" element (see line number 24) within that element (step S206).

[0087] 2A and 2B, the value of the “test_ref” attribute of the extracted “criterion” element is “com.xxx:tst:20191992001.” Therefore, the extraction unit 20A searches for elements whose “id” attribute is “com.xxx:tst:20191992001” from the elements included in the “tests” element (see lines 29-38 in the vulnerability testing method information 16A), and extracts the “rpminfo_test” element in lines 30-33 in the vulnerability testing method information 16A (step S212).

[0088] In step S210, since the element name is "rpminfo_test", the extraction unit 20A determines it to be "other" in step S210, and the process proceeds to step S206.

[0089] In step S206, the extraction unit 20A extracts the "criterion" element included in line number 26 in the vulnerability testing method information 16A. Then, in step S208, the extraction unit 20A searches for "com.xxx:tst:20191992001," which is the value of the "test_ref" attribute of the element, as an element having an "id" attribute. Through this search process, the extraction unit 20A extracts the "textfilecontent54_test" element included in lines numbered 34-37 in the vulnerability testing method information 16A (step S208).

[0090] Since the element name is "textfilecontent54_test," the extraction unit 20A determines it to be "textfilecontent54_test" in step S210 and proceeds to step S212. The extraction unit 20A then searches for an element having the value "com.xxx:obj20191992001" of the "object_ref" attribute of the "textfilecontent54_test" element as its "id" attribute value from the elements immediately below the "objects" attribute (see lines 39-48 in the vulnerability testing method information 16A). The extraction unit 20A extracts the "textfilecontent54_object" element included in lines 43-47 in the vulnerability testing method information 16A (step S212). Then, the extraction unit 20A registers "file" in the type field of the first management information 16B and " / etc / xxx-module.conf", which is the value of the "filepath" element under the "textfilecontent54_object" element, in the value field of the first management information 16B as the first file path information (step S214). Then, the process returns to step S206.

[0091] Then, in step S206, since there are no unprocessed "criterion" elements, the process proceeds to step S202, and since there are no unobtained "definition" elements, the process ends.

[0092] At this point, only the record for " / etc / xxx-module.conf" exists in the vulnerability testing method information 16A.

[0093] Next, the registration unit 20B reads the first file path information " / etc / xxx-module.conf," which is a value corresponding to the type "file," from the vulnerability testing method information 16A, and copies the data stored in the location indicated by the file path represented by the first file path information in the test target 30 to the file storage unit 16D. At this time, the registration unit 20B assigns, for example, a sequence number to the file name to prevent duplication of file names of files stored in the file storage unit 16D, and stores the file in the file storage unit 16D. In this example, for example, the registration unit 20B assigns the file name "12345." Then, the registration unit 20B additionally registers, in the second management information 16C, a record associating the first file path information " / etc / xxx-module.conf" with the second file path information " / backup / 12345," which is the copy destination.

[0094] When testing the vulnerability of the test target 30, the vulnerability testing tool 50A searches the second management information 16C, and if the second file path information is associated with the first file path information, which is the file path to be accessed, the vulnerability testing tool 50A references the file stored in the location indicated by the file path represented by the second file path information. In this example, when accessing " / etc / xxx-module.conf", the vulnerability testing tool 50A uses " / etc / xxx-module.conf" instead.

[0095] Therefore, the vulnerability testing tool 50A can appropriately evaluate the impact of an attack on the vulnerability of the test target 30 without directly accessing the test target 30.

[0096] As described above, the information processing device 10 of this embodiment includes an extraction unit 20A and a registration unit 20B. The extraction unit 20A extracts first file path information that represents a file path in the inspection target 30 of a file that is used in a vulnerability inspection of the inspection target 30 by the vulnerability inspection tool 50A. The registration unit 20B associates the first file path information with second file path information that represents a file path to a file copied from the inspection target 30 using the first file path information, and registers the association in the second management information 16C.

[0097] As described above, in the information processing device 10 of this embodiment, the registration unit 20B generates the second management information 16C. Therefore, the vulnerability testing tool 50A accesses a file using the second management information 16C and performs a vulnerability test. In detail, when determining compliance with a vulnerability indicated in the vulnerability information, the vulnerability testing tool 50A uses a file stored in a location in the file storage unit 16D indicated by a file path represented by the second file path information associated with the first file path information in the second management information 16C, instead of a location in the test target 30 indicated by a file path represented by the first file path information in the test target 30.

[0098] Therefore, in the information processing device 10 of this embodiment, even in an environment where the vulnerability testing tool 50A cannot directly access the test target 30, the impact of an attack on the vulnerability of the test target 30 can be appropriately evaluated.

[0099] Therefore, the information processing device 10 of this embodiment can appropriately evaluate the impact when the vulnerability of the inspection target 30 is attacked, even in an environment where the inspection target 30 cannot be directly accessed.

[0100] In the above embodiment, in steps S212 and S214, for test items that manipulate files, the file paths to be manipulated are recorded as first file path information in the first management information 16B. However, during vulnerability testing, there are cases where a command is executed on the test target 30 and the output result is used instead of the file contents. In this case, it is possible to handle these vulnerability tests by making the following modifications. As an example of such a vulnerability test, the case of "uname_test" will be described.

[0101] "uname_test" executes the command "uname" that outputs kernel information and performs vulnerability testing based on that output. In step S208, if the corresponding element name is "uname_test", the extraction unit 20A adds a record in which "command" is associated with the type field of the first management information 16B and "uname" is associated with the value field.

[0102] Then, the registration unit 20B changes its operation according to the type registered in the first management information 16B, and if the type is "file", it copies the file from the inspection target 30 as in the above embodiment, and if the type is "command", it executes the command that is the value of the "value" field in the first management information 16B on the inspection target 30, and saves the result as a file in the file memory unit 16D.

[0103] (Second embodiment) In this embodiment, a form will be described in which first file path information is extracted using an access log of a vulnerability testing tool.

[0104] FIG. 8 is a functional block diagram of an example of the information processing system 2 of this embodiment.

[0105] The information processing system 2 includes an information processing device 11, an inspection target 30, and an inspection device 41. The information processing device 11 and the inspection target 30 can be connected to each other so that they can communicate with each other directly or via a network or the like. The information processing device 11 and the inspection device 41 are connected to each other so that they can communicate with each other directly or via a network or the like. The inspection target 30 and the inspection device 41 are connected to each other so that they can communicate with each other when an access log, which will be described later, is generated, but they do not need to be connected after the access log is generated. The inspection target 30 is the same as in the above embodiment.

[0106] The inspection device 41 is an information processing device for executing a vulnerability inspection on the inspection target 30. The inspection device 41 includes a communication unit 42, a UI unit 44, a storage unit 47, and a processing unit 51. The communication unit 42, the UI unit 44, the storage unit 47, and the processing unit 51 are communicatively connected via a bus 48 or the like. The inspection device 41 is similar to the inspection device 40 of the above embodiment, except that it includes the storage unit 47 instead of the storage unit 46 and the processing unit 51 instead of the processing unit 50.

[0107] The storage unit 47 stores various types of information. In this embodiment, the storage unit 47 stores an access log 47A. Details of the access log 47A will be described later.

[0108] The processing unit 51 executes information processing in the inspection device 41. The processing unit 51 includes a vulnerability inspection tool 50A.

[0109] When the vulnerability checking tool 50A is in a state where it can directly access the inspection target 30, the processing unit 51 starts the vulnerability checking tool 50A and causes the vulnerability checking tool 50A to perform a vulnerability check on the inspection target 30. Then, the processing unit 51 generates an access log 47A using information on files accessed when the vulnerability checking tool 50A performs a vulnerability check on the inspection target 30. The access log 47A is information including the file paths of files accessed when the vulnerability checking tool 50A performs a vulnerability check on the inspection target 30.

[0110] The processing unit 51 generates the access log generated by the vulnerability testing tool 50A as the access log 47A. The vulnerability testing tool 50A may not have a function for generating an access log. In this case, the processing unit 51 may generate the access log 47A by using an OS audit log obtained when the vulnerability testing tool 50A performs a vulnerability test on the test target 30. The processing unit 51 may also generate the access log 47A by creating a module that monitors file accesses, such as a Linux Security Module, and acquiring information about files accessed by the vulnerability testing tool 50A. The processing unit 51 stores the generated access log 47A in the storage unit 47. The processing unit 51 may also transmit the generated access log 47A to the information processing device 11. In this case, the information processing device 11 may store the access log 47A received from the testing device 41 in the storage unit 17.

[0111] The information processing device 11 will be described.

[0112] The information processing device 11 includes a communication unit 12, a UI unit 14, a storage unit 17, and a processing unit 21. The information processing device 11 is similar to the information processing device 10 except that the information processing device 11 includes the storage unit 17 and the processing unit 21 instead of the storage unit 16 and the processing unit 20.

[0113] The storage unit 16 is similar to the storage unit 17 except that it stores excluded file information 17A instead of vulnerability testing method information 16A. The processing unit 21 is similar to the processing unit 20 except that it includes an extraction unit 21A instead of the extraction unit 20A.

[0114] The extraction unit 21A extracts the first file path information based on the access log 47A and the excluded file information 17A.

[0115] The excluded file information 17A is information that pre-records file information about files that are not used in vulnerability testing among the files identified by the file paths registered in the access log 47A. The excluded file information 17A may be pre-recorded by the processing unit 21 or an external device, etc., with file information about general files that are not used in vulnerability testing. For example, if the vulnerability testing tool 50A is a tool that creates a log file, the log file itself is not used in vulnerability testing. Therefore, the processing unit 21 may pre-register information that represents the log file itself in the excluded file information 17A.

[0116] The extraction unit 21A extracts, from among the file paths recorded in the access log 47A, file paths for accessing files other than those defined in the excluded file information 17A, as first file path information.

[0117] Then, the extraction unit 21A associates the extracted first file path information with the type of file stored in the location indicated by the file path specified by the first file path information, and registers them in the first management information 16B.

[0118] The registration unit 20B and the construction unit 20C are the same as those in the above embodiment.

[0119] Next, an example of the flow of information processing executed by the information processing device 11 of this embodiment will be described.

[0120] FIG. 9 is a flowchart showing an example of the flow of information processing executed by the information processing device 11 of this embodiment.

[0121] The extraction unit 21A extracts the first file path information based on the access log 47A and the excluded file information 17A (step S300).

[0122] The registration unit 20B uses the first file path information extracted in step S300 and registered in the first management information 16B to copy and store the file from the inspection target 30 to the file storage unit 16D (step S302).

[0123] Then, the registration unit 20B associates the second file path information representing the file path to the file stored in the file storage unit 16D in step S302 with the first file path information used when copying the file from the inspection target 30, and registers them in the second management information 16C (step S304). Then, this routine ends.

[0124] As described above, in this embodiment, the extraction unit 21A extracts the first file path information based on the access log 47A and the excluded file information 17A.

[0125] In the above embodiment, the extraction unit 20A extracted the first file path information, which is the file path in the inspection target 30 of the file required for vulnerability testing, from the vulnerability testing method information 16A. In this case, the vulnerability information included in the vulnerability testing method information 16A needs to be vulnerability information with publicly available specifications, such as OVAL. However, some vulnerability testing tools 50A perform vulnerability testing using private vulnerability information, and it may be impossible to analyze the vulnerability information. In this case, it may be difficult for the extraction unit 20A to extract the first file path information from the vulnerability testing method information 16A.

[0126] On the other hand, in this embodiment, the extraction unit 21A extracts the first file path information based on the access log 47A and the excluded file information 17A.

[0127] Therefore, in the information processing device 11 of this embodiment, by extracting the first file path information using the access log 47A, it is possible to appropriately evaluate the impact when a vulnerability in the inspection target 30 is attacked, even if publicly available vulnerability information of a specification such as OVAL is not used.

[0128] Furthermore, in the information processing device 11, the first file path information is extracted based on the access log 47A and the excluded file information 17A, so that it is possible to prevent file paths to unnecessary files from being registered in the first management information 16B.

[0129] Next, an example of the hardware configuration of the information processing device 10 and the information processing device 11 of the above embodiment will be described.

[0130] FIG. 10 is a diagram showing an example of the hardware configuration of the information processing device 10 and the information processing device 11 according to the above embodiment.

[0131] The information processing device 10 and the information processing device 11 of the above embodiments are equipped with a control device such as a CPU (Central Processing Unit) 90B, a storage device such as a ROM (Read Only Memory) 90C, a RAM (Random Access Memory) 90D, and an HDD (Hard Disk Drive) 90E, an I / F section 90A that interfaces with various devices, and a bus 90F that connects each section, and have a hardware configuration that uses a normal computer.

[0132] In the information processing device 10 and the information processing device 11 of the above embodiment, the CPU 90B reads out a program from the ROM 90C onto the RAM 90D and executes it, thereby realizing the above-mentioned respective units on the computer.

[0133] The programs for executing the above processes executed by the information processing device 10 and the information processing device 11 of the above embodiment may be stored in the HDD 90E. Also, the programs for executing the above processes executed by the information processing device 10 and the information processing device 11 of the above embodiment may be provided by being pre-installed in the ROM 90C.

[0134] Furthermore, the programs for executing the above processes executed by the information processing device 10 and the information processing device 11 of the above embodiments may be stored in an installable or executable file format on a computer-readable storage medium such as a CD-ROM, CD-R, memory card, DVD (Digital Versatile Disc), or flexible disk (FD) and provided as a computer program product. Furthermore, the programs for executing the above processes executed by the information processing device 10 and the information processing device 11 of the above embodiments may be stored on a computer connected to a network such as the Internet and provided by downloading via the network. Furthermore, the programs for executing the above processes executed by the information processing device 10 and the information processing device 11 of the above embodiments may be provided or distributed via a network such as the Internet.

[0135] Although the embodiments of the present invention have been described above, the above embodiments are presented as examples and are not intended to limit the scope of the invention. This novel embodiment can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. This embodiment and its modifications are included within the scope and spirit of the invention, and are also included in the invention and its equivalents as defined in the claims. [Explanation of symbols]

[0136] 10, 11 Information processing device 20A, 21A extraction part 20B Registration Department 20C Construction Department 50A Vulnerability Testing Tool

Claims

1. an extracting unit that extracts first file path information representing a file path in the inspection target that is used for vulnerability testing of the inspection target by a vulnerability testing tool; a registration unit that associates second file path information, which indicates a file path to a file copied from the inspection target using the first file path information, with the first file path information and registers the second file path information in second management information; An information processing device comprising:

2. The registration unit storing the file copied from the inspection target in a file storage unit using the first file path information; the second file path information represents a file path to the file in the file storage unit; The information processing device according to claim 1 .

3. The extraction unit registering the extracted first file path information in first management information; The registration unit copying the file from the inspection target to the file storage unit using the first file path information registered in the first management information; the second file path information representing a file path to the file in the file storage unit is associated with the first file path information and registered in second management information; The information processing device according to claim 2 .

4. The extraction unit extracting the first file path information based on vulnerability testing method information used by the vulnerability testing tool to test the vulnerability of the test target; The information processing device according to claim 1 .

5. The extraction unit extracting, as the first file path information, file paths for accessing files other than those specified in the excluded file information from among the file paths recorded in the access log, based on an access log in which file paths in the test target that are accessed when the vulnerability test tool executes a vulnerability test on the test target are recorded, and excluded file information that specifies file information that is not used in the vulnerability test; The information processing device according to claim 1 .

6. a construction unit that constructs a virtual file system that associates the first file path information with the file stored in the file path represented by the second file path information that is associated with the first file path information; The information processing device according to claim 1 , comprising:

7. An information processing method executed by an information processing device, extracting first file path information representing a file path in the test target used for vulnerability testing of the test target by a vulnerability testing tool; a step of registering second file path information, which indicates a file path to a file copied from the inspection target using the first file path information, in association with the first file path information in second management information; An information processing method including:

8. extracting first file path information representing a file path in the test target used for vulnerability testing of the test target by a vulnerability testing tool; a step of registering second file path information, which indicates a file path to a file copied from the inspection target using the first file path information, in association with the first file path information in second management information; An information processing program that causes a computer to execute the above.

Images