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

[0005] ,

[0001] Embodiments of the present invention relate to an information processing apparatus, an information processing method, and an information processing program.

Background Art

[0002] Numerous new vulnerabilities are reported every day, and based on vulnerability information provided by vendors and others, the impact when vulnerabilities in various systems using computers and the like are attacked is evaluated. In the evaluation of the impact, it is determined whether the occurrence conditions of the vulnerabilities shown in the provided vulnerability information match the inspection target, and when they match, the risk is evaluated. In addition, vulnerability inspection tools are used to automatically perform conformity judgments on the vast number of vulnerability information provided every day and inspect the vulnerabilities of the inspection target.

[0003] There are cases where the vulnerability inspection tool cannot directly access the inspection target due to the shipment of the inspection target or the like. Therefore, a method has been disclosed in which a digital twin is generated by copying all the information included in the inspection target, and the digital twin is inspected by the vulnerability inspection tool.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

[0006] The problem that this 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 of an attack on a vulnerability of a target being tested, even in an environment where direct access to the target is not possible. [Means for solving the problem]

[0007] The information processing device of this embodiment comprises an extraction unit and a registration unit. The extraction unit extracts first file path information representing the file path in the target of the vulnerability test used for vulnerability testing of the target of the vulnerability test tool. The registration unit associates the first file path information with second file path information representing the file path to a file copied from the target of the vulnerability test and registers this information in second management information. [Brief explanation of the drawing]

[0008] [Figure 1] Functional block diagram of an information processing system. [Figure 2A] A schematic diagram of the data structure of vulnerability testing methodology information. [Figure 2B] A schematic diagram of the data structure of vulnerability testing methodology information. [Figure 3] Diagram illustrating the structure of OVAL. [Figure 4] A schematic diagram of the data structure of the first management information. [Figure 5] A schematic diagram of the data structure of the second management information. [Figure 6] A flowchart illustrating the flow of information processing performed by an information processing device. [Figure 7] A flowchart illustrating the extraction process performed by the extraction unit. [Figure 8]Functional block diagram of an information processing system. [Figure 9] A flowchart illustrating the flow of information processing performed by an information processing device. [Figure 10] This is a hardware configuration diagram. [Modes for carrying out the invention]

[0009] The information processing apparatus, information processing method, and information processing program of this embodiment will be described in detail below with reference to the attached drawings.

[0010] In the following descriptions of each embodiment, parts denoted by the same reference numeral have substantially the same function, and explanations of overlapping parts will be omitted as appropriate.

[0011] (First Embodiment) Figure 1 is a functional block diagram of an example of the information processing system 1 of this embodiment.

[0012] The information processing system 1 comprises an information processing device 10, an object to be inspected 30, and an inspection device 40. The information processing device 10 and the object to be inspected 30 are connectable via communication, either directly or via a network. The information processing device 10 and the inspection device 40 are also connected via communication, either directly or via a network.

[0013] The inspection target 30 is a system to be evaluated for vulnerabilities. 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 an App (Application program, or Application software). The OS and OSS are, for example, Linux (registered trademark), Unix (registered trademark), Windows (registered trademark), Android (registered trademark), iOS (registered trademark), etc., but are not limited to these. These software operate by using or including one or more software components. The software components may be referred to as drivers, services, libraries, etc. For example, Linux operates by using or including the kernel function of the OS itself and software components such as a number of device drivers and services.

[0014] The inspection device 40 is an information processing device for performing a 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, and the storage unit 46 are communicably connected to the processing unit 50 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 apparatus 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 causing a processor such as a CPU (Central Processing Unit) to execute a program, that is, by software. Also, the vulnerability inspection tool 50A may be realized by a processor such as a dedicated IC, that is, by hardware. Also, the vulnerability inspection tool 50A may be realized by using software and hardware in combination. Also, the vulnerability inspection tool 50A may be installed in the information processing apparatus 10.

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

[0019] Vulnerability information is information that represents a vulnerability. The vulnerability information includes information regarding the vulnerability. Specifically, for example, the vulnerability information includes information representing a conformity condition that conforms to the vulnerability, an evaluation criterion including a risk value for each conformity condition, an assumed influence range given to the inspection target 30 by the vulnerability, and a countermeasure means for dealing with the vulnerability, and the like. The vulnerability information is provided from CVE (Common Vulnerabilities and Exposures), NVD (National Vulnerability Database), JVN (Japan Vulnerability Notes), and the like.

[0020] [[ID=I1]] The vulnerability information is provided not only in ordinary text but also in a security inspection language so as to be machine-processable. In the present embodiment, an example in which the vulnerability information is described in OVAL (Open Vulnerability and Assessment Language), which is an example of a security inspection language, will be described.

[0021] The vulnerability testing tool 50A performs a compliance check to determine whether the compliance conditions of the vulnerability information meet those of the target 30. If it does, it assesses the risk, and if the risk is high, it applies patches or implements workarounds provided by the software vendor, etc. Through these processes, the vulnerability testing tool 50A performs a vulnerability check on the target 30.

[0022] In determining whether a vulnerability is present, not only the package information of the installed software included in the target system 30 is used, but also the contents of files such as configuration files. Security testing languages ​​such as OVAL allow the description of compatibility conditions using file paths and values. If the vulnerability testing tool 50A has direct access to the target system 30, it determines whether a vulnerability is present by checking the package information and file contents of the target system 30. Examples of vulnerability testing tools 50A include Vuls (VULnerability Scanner).

[0023] The information processing device 10 comprises 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 communicated with each other via a bus 18 or the like.

[0024] The communication unit 12 communicates with the inspection target 30 and the inspection device 40, either directly or via a network. The UI unit 14 includes a display unit 14A and an input unit 14B. The display unit 14A is a display that shows various types of information. The input unit 14B receives operation instructions from the user. The input unit 14B is, for example, a pointing device such as a mouse or a keyboard. The storage unit 16 stores various types of information. The storage unit 16 may be a storage device located outside the information processing device 10. For example, the storage unit 16 may be mounted on 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, file storage unit 16D, and virtual file system 16E. Details of this 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 implemented by, for example, one or more processors. For example, each of the above units may be implemented 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 implemented by a dedicated IC or other processor, i.e., by hardware. Each of the above units may be implemented by using both software and hardware. When multiple processors are used, each processor may implement one of the above units, or two or more of the above units. Furthermore, at least one of the above units may be provided on an external information processing device connected to the information processing device 10 via a network.

[0027] As mentioned above, if the vulnerability testing tool 50A has direct access to the target 30, the vulnerability testing tool 50A determines whether the target 30 is vulnerable by checking the package information and file contents. However, if the target 30 is shipped or otherwise in an environment where the vulnerability testing tool 50A cannot directly access the target 30, the vulnerability testing tool 50A cannot directly test the target 30. Another method involves generating a digital twin that copies all the information contained in the target 30, and performing vulnerability detection on the digital twin using the vulnerability testing tool 50A. However, generating a digital twin for each of the vast number of target 30s would require an enormous amount of data storage and is not practical. With conventional technology, in environments where the vulnerability testing tool 50A cannot directly access the target 30, it was difficult to properly evaluate the impact if the vulnerability in the target 30 were attacked.

[0028] Therefore, the processing unit 20 of this embodiment comprises at least an extraction unit 20A and a registration unit 20B. Furthermore, the processing unit 20 may also be configured to include a construction unit 20C.

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

[0030] The first file path information is information representing the file path within the 30 items under inspection that is used for vulnerability testing of the 30 items under inspection.

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

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

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

[0034] Figures 2A and 2B show an example of how vulnerability testing method information 16A can be composed of vulnerability testing method information 16A1 shown in Figure 2A and vulnerability testing method information 16A2 shown in Figure 2B. Figures 2A and 2B also show an example of how vulnerability testing method information 16A can be an OVAL file written in XML (Extensible Markup Language). Note that actual OVAL files contain XML namespace information, but this is omitted in the examples shown in Figures 2A and 2B for simplicity.

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

[0036] The OVAL file information is the bibliographic information for vulnerability testing method information 16A. The test definition is information representing the definition of vulnerability testing. The test target is information representing the target files, etc., used for vulnerability testing. The state of the test target is information representing the state that the files, etc., used for vulnerability testing should satisfy.

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

[0038] The generator represents the bibliographic information for vulnerability testing method information 16A, and corresponds to the OVAL file information mentioned above. The bibliographic information includes, for example, the title, version, and creation date. The `definitions` element represents a collection of vulnerability information. Directly under `definitions`, there are multiple `definition` elements, each representing an individual vulnerability. `tests` represents a set of test conditions that describe the compliance requirements for vulnerability information. Individual test conditions are described within elements directly below `tests`. The set of test conditions represents the test definition. objects: Represents a set of targets for the test conditions. Elements describing individual targets exist directly under objects. `states`: Represents a set of conditions (values) that the object under test must satisfy. Individual conditions are described by elements directly under `objects`. The set of conditions represents the state of the object under test.

[0039] The `definition` element corresponds to a single vulnerability entry and consists of a `metadata` element that represents the content of the vulnerability information, such as the vulnerability description and the magnitude of the risk, and a `criteria` element that represents the conditions for compliance with the vulnerability. The conditions for compliance with the vulnerability are expressed as a logical expression of multiple conditions, and the `criterion` element representing each condition is expressed as a logical expression using the `operator` attribute value (for example, "AND") of the parent `criteria` element. 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] The elements under the `tests` element (for example, "textfilecontent54_test") have an `object` element representing the test target and a `state` element representing the conditions that the target must satisfy. The `object` element has an `object_ref` attribute. The `object_ref` attribute points to the element directly under the `objects` element whose ID is the value of the `object_ref` attribute. Similarly, the `state` element also has an `object_ref` attribute. The `state` element points to the element directly under the `states` element whose ID is the value of the `states_ref` attribute (see Figure 3). Figure 3 is an explanatory diagram of an example of the structure of OVAL. Figure 3 shows an example of the relationship between elements whose IDs are the attribute values ​​mentioned above. Return to Figures 2A and 2B and continue the explanation.

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

[0042] rpminfo_test: This command tests whether the target software is included in the Linux software package management system, RPM. The `object` element specifies the package name, and the `state` element specifies conditions regarding the software version. `textfilecontent54_test`: This command tests whether a specified file contains a particular string. The `object` element identifies the file, and the `state` element specifies the condition for the string to be contained within the file. xinetd_test: This command examines the xinetd configuration file used for network settings and tests its configuration. The object element specifies the name of the configuration item, and the state element specifies the conditions that the configuration value must satisfy.

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

[0044] The extraction unit 20A extracts first file path information representing the file paths of files included in the target 30, which will be used for vulnerability testing of the target 30 by the vulnerability testing tool 50A, based on the vulnerability testing method information 16A. Specifically, the extraction unit 20A reads the vulnerability testing method information 16A, obtains individual compliance conditions for each vulnerability specified in the vulnerability testing method information 16A, and reads the element values ​​from the vulnerability testing method information 16A for each compliance condition. Through this reading process, the extraction unit 20A extracts the file paths of files included in the target 30 that the vulnerability testing tool 50A will use for vulnerability testing, as first file path information.

[0045] Specifically, for example, the extraction unit 20A reads the vulnerability testing method information 16A and obtains one definition element contained in the vulnerability testing method information 16A to obtain one piece of vulnerability information. Then, each time the extraction unit 20A obtains one piece of vulnerability information, it obtains the compliance conditions represented by that vulnerability information. For example, the extraction unit 20A obtains the compliance conditions by obtaining the criteria element directly under the definition element.

[0046] Then, the extraction unit 20A obtains one conformance condition by acquiring one criteria element, and for each condition, it extracts the element directly under the tests element that has the same ID as the test_ref attribute included in the conformance condition.

[0047] For example, suppose the element name of the extracted element is "textfilecontent54_test", which represents the element that will be tested and the conditions that the element will satisfy. In this case, the extraction unit 20A extracts elements that are directly under the object element representing the test target, contained within the element "textfilecontent54_test", and whose ID matches the attribute value of object_ref. Then, the extraction unit 20A extracts the value of the "filepath" element contained within 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 xinetd configuration file used to configure the network is examined and the configuration is tested, the extraction unit 20A extracts the same file path (for example, " / etc / xinted.conf") as the first file path information, regardless of whether it is an object element.

[0049] The extraction unit 20A then registers the extracted first file path information in the first management information 16B.

[0050] Figure 4 is a schematic diagram of an example of the data structure of the first management information 16B. The first management information 16B has multiple records that associate a type with a value.

[0051] The extraction unit 20A registers the extracted first file path information in association with the type of file stored at the location indicated by the file path represented by the first file path information. That is, the extraction unit 20A registers the first file path information, which is the file path of the file to be used for vulnerability testing in the target 30, in the "Value" field of the first management information 16B, and registers "File" in the "Type" field corresponding to the "Value". In addition, the first management information 16B may further store records in which "Command" is associated in the "Type" field and "Command required for vulnerability testing" is associated in 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 uses the first file path information to associate it with the second file path information, which represents the file path to the file copied from the inspection target 30, and registers it in the second management information 16C.

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

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

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

[0057] Let's return to Figure 1 and continue the explanation. Next, we will describe the construction unit 20C. The processing unit 20 may or may not have a configuration that includes the construction unit 20C. In this embodiment, we will describe a configuration that includes either the processing unit 20 or the construction unit 20C as an example.

[0058] The construction unit 20C constructs a virtual file system 16E that associates the first file path information registered in the second management information 16C with the files stored in the location indicated by the file path represented by the second file path information 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 the 30 vulnerabilities being tested, using files stored in locations indicated by file paths, for example, those 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 the file using the second management information 16C and performs a vulnerability test. More specifically, when determining compliance with the vulnerability information, the vulnerability testing tool 50A uses a file stored in the file storage unit 16D, which is indicated by the 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 the file path represented by the first file path information in the test target 30.

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

[0062] Furthermore, depending on the vulnerability testing tool 50A, it may be difficult to access files stored in the file storage unit 16D, which are indicated by the 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 in configurations where the vulnerability testing tool 50A has difficulty accessing files stored in the file storage unit 16D, by using the virtual file system 16E and utilizing files associated with the first file path information, the impact of an attack on the vulnerability of the target 30 can be appropriately evaluated.

[0065] Furthermore, the extraction process of first file path information by the extraction unit 20A, the registration process by the registration unit 20B that associates the first file path information with the second file information and registers it in the second management information 16C, the construction process of the virtual file system 16E by the construction unit 20C, and the vulnerability test by the vulnerability testing tool 50A do not need to be performed in this order consecutively, and each process may be executed at the appropriate time.

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

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

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

[0069] The extraction unit 20A performs an extraction process to extract first file path information representing the file path of the file used for vulnerability testing of the target 30 by the vulnerability testing tool 50A (step S100).

[0070] The registration unit 20B copies the file from the object to be inspected 30 to the file storage unit 16D and stores it using the first file path information extracted in step S100 and registered in the first management information 16B (step S102).

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

[0072] Next, we will explain a specific example of the detailed flow of the extraction process performed by the extraction unit 20A.

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

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

[0075] Then, the extraction unit 20A obtains one unprocessed "definition" element from the multiple vulnerability information read in step S200 (step S202). Multiple "definition" elements exist in the vulnerability testing method information 16A read in step S200. Therefore, if the extraction unit 20A is unable to obtain an unprocessed "definition" element, that is, if the processing (i.e., acquisition) of all "definition" elements contained in the vulnerability testing method information 16A read in step S200 is completed (step S202: failure), the routine terminates.

[0076] If the extraction unit 20A obtains one unprocessed "definition" element (step S202: success), it proceeds to step S204. In step S204, the extraction unit 20A obtains a "criteria" element directly below the "definition" element obtained in step 202 (step S204). Then, the extraction unit 20A obtains one unprocessed "criterion" element directly below the "criteria" element obtained in step S204 (step S206: success), and proceeds to step S208. If the extraction unit 20A finds that all "criterion" elements directly below the "criteria" element obtained in step S204 have already been processed, i.e., that it could not obtain an unprocessed "criterion" element (step S206: failure), it 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 as the "id" attribute (step S208).

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

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

[0080] In step S212, the extraction unit 20A searches for elements directly under the "objects" element that have the same "object_ref" attribute value and "id" attribute value as the element named "textfilecontent54_test" (step S212). Then, the extraction unit 20A takes the value of the "filepath" element directly under the element found in step S212 as the first file path information and registers it in the first management information 16B, associating it with the type "file" (step S214). Then, the process proceeds to step S206.

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

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

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

[0084] In this case, as explained using the flowchart in Figure 7, the extraction unit 20A first extracts the file path of the file to be used for vulnerability testing as first file path information. More specifically, in the process of step S200, the extraction unit 20A performs parsing of the vulnerability testing method information 16A shown in Figures 2A and 2B.

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

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

[0087] Here, as shown in Figures 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 contained in the "tests" element (referencing 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 proceeds to step S206.

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

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

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

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

[0093] Next, the registration unit 20B reads the first file path information " / etc / xxx-module.conf", which corresponds to the type "file", from the vulnerability testing method information 16A, and copies the data stored at the location indicated by the file path represented by the first file path information in the target for testing 30 to the file storage unit 16D. At this time, the registration unit 20B adds a sequence number or the like to the file name to the file storage unit 16D to prevent duplication of file names, and stores it in the file storage unit 16D. In this example, for example, the registration unit 20B uses the file name "12345". Then, the registration unit 20B adds a record to the second management information 16C that associates the first file path information " / etc / xxx-module.conf" with the copy destination, the second file path information " / backup / 12345".

[0094] When performing vulnerability testing on the 30 target files, the vulnerability testing tool 50A searches for the second management information 16C. If the second file path information is associated with the first file path information, which is the file path to be accessed, it refers to the file stored at the location indicated by the file path represented by the second file path information. In this example, when the vulnerability testing tool 50A accesses " / etc / xxx-module.conf", it will use " / etc / xxx-module.conf" instead.

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

[0096] As described above, the information processing device 10 of this embodiment comprises an extraction unit 20A and a registration unit 20B. The extraction unit 20A extracts first file path information representing the file path in the target 30 of the files used for vulnerability testing of the target 30 by the vulnerability testing tool 50A. The registration unit 20B associates the first file path information with second file path information representing the file path to the file copied from the target 30 of the target 30 and registers it in the second management information 16C.

[0097] Thus, 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 uses the second management information 16C to access the file and perform the vulnerability test. Specifically, when the vulnerability testing tool 50A determines whether a vulnerability indicated in the vulnerability information is applicable, it uses a file stored in the file storage unit 16D, indicated by the file path represented by the second file path information associated with the first file path information in the second management information 16C, instead of the location in the test target 30 indicated by the file path represented by the first file path information in the test target 30.

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

[0099] Therefore, the information processing device 10 of this embodiment can appropriately evaluate the impact of an attack on the vulnerability of the object to be inspected 30, even in an environment where direct access to the object to be inspected 30 is not possible.

[0100] In the above embodiment, steps S212 and S214 described a method in which the file path to be manipulated is recorded as first file path information in the first management information 16B for test items that manipulate files. However, during vulnerability testing, it is sometimes necessary to execute a command on the test target 30 and use the output result, rather than the contents of the file. In this case, these vulnerability tests can also be handled by modifying the method as follows. An example of such a vulnerability test will be described for "uname_test".

[0101] "uname_test" executes the command "uname" which 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 to the first management information 16B with "command" associated in the type field and "uname" in the value field.

[0102] The registration unit 20B then changes its operation according to the type registered in the first management information 16B. If the type is "file", it copies the file from the inspection target 30 as in the above embodiment. If the type is "command", it executes the command, which 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 to the file storage unit 16D.

[0103] (Second embodiment) In this embodiment, a method for extracting first file path information using the access log of a vulnerability testing tool is described.

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

[0105] The information processing system 2 comprises an information processing device 11, an object to be inspected 30, and an inspection device 41. The information processing device 11 and the object to be inspected 30 can be connected to each other via communication, either directly or via a network. The information processing device 11 and the inspection device 41 are connected to each other via communication, either directly or via a network. The object to be inspected 30 and the inspection device 41 are connected to each other via communication when generating the access log described later, but do not need to be connected after the generation of the access log. The object to be inspected 30 is the same as in the above embodiment.

[0106] The inspection device 41 is an information processing device for performing vulnerability testing on the object to be tested 30. The inspection device 41 comprises 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 communicated to each other via a bus 48 or the like. The inspection device 41 is the same as the inspection device 40 of the above embodiment, except that it has a storage unit 47 instead of a storage unit 46 and a processing unit 51 instead of a processing unit 50.

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

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

[0109] When the vulnerability testing tool 50A has direct access to the target device 30, the processing unit 51 starts the vulnerability testing tool 50A and has the vulnerability testing tool 50A perform a vulnerability scan on the target device 30. The processing unit 51 then generates an access log 47A using information about the files accessed by the vulnerability testing tool 50A when it performed the vulnerability scan on the target device 30. The access log 47A contains information including the file paths of the files accessed by the vulnerability testing tool 50A when it performed the vulnerability scan on the target device 30.

[0110] The processing unit 51 generates the access log generated by the vulnerability testing tool 50A as access log 47A. In some cases, the vulnerability testing tool 50A may not have a function to generate access logs. In this case, the processing unit 51 may generate access log 47A by using the OS audit log at the time the vulnerability testing tool 50A performs the vulnerability testing on the target 30. Alternatively, the processing unit 51 may create a module that monitors file access, such as a Linux Security Module, and generate access log 47A by obtaining information about the 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 send the generated access log 47A to the information processing device 11. In this case, the information processing device 11 should store the access log 47A received from the testing device 41 in the storage unit 17.

[0111] I will now describe the information processing device 11.

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

[0113] The storage unit 16 is the same as the storage unit 17 except that it stores excluded file information 17A instead of vulnerability testing method information 16A. The processing unit 21 is the same as the processing unit 20 except that it has an extraction unit 21A instead of an 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] Excluded file information 17A is information that pre-records file information about files that are not used for vulnerability testing, among the files identified by the file paths registered in the access log 47A. Excluded file information 17A only needs to have file information for general files that are not used for vulnerability testing pre-recorded by the processing unit 21 or an external device. For example, if the vulnerability testing tool 50A is a tool that creates log files, the log files themselves are not used for vulnerability testing. Therefore, the processing unit 21 only needs to pre-register information representing the log files themselves in the excluded file information 17A.

[0116] The extraction unit 21A extracts file paths from the access log 47A that are used to access files other than those specified in the excluded file information 17A, as first file path information.

[0117] The extraction unit 21A then associates the extracted first file path information with the type of file stored in the location represented by the file path identified by the first file path information and registers this information in the first management information 16B.

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

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

[0120] Figure 9 is a flowchart showing an example of the information processing flow performed 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 copies the file from the object to be inspected 30 to the file storage unit 16D and stores it using the first file path information extracted in step S300 and registered in the first management information 16B (step S302).

[0123] Then, the registration unit 20B associates the second file path information, which represents the file path to the file stored in step S302 in the file storage unit 16D, with the first file path information used when copying the file from the inspection target 30, and registers it 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 first file path information, which is the file path of the file to be inspected 30 necessary for vulnerability testing, from the vulnerability testing method information 16A. In this case, the vulnerability information included in the vulnerability testing method information 16A must be publicly available vulnerability information, such as OVAL. However, some vulnerability testing tools 50A perform vulnerability testing using non-public 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 first file path information from the vulnerability testing method information 16A.

[0126] On the other hand, in this embodiment, the extraction unit 21A extracts 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 first file path information using the access log 47A, it is possible to appropriately evaluate the impact of an attack on the vulnerability of the target 30, even without using publicly available vulnerability information such as OVAL.

[0128] Furthermore, since the information processing device 11 extracts first file path information based on the access log 47A and the excluded file information 17A, it is possible to suppress the registration of file paths to unnecessary files in the first management information 16B.

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

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

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

[0132] In the information processing devices 10 and 11 of the above embodiment, each of the above components is realized on the computer by the CPU 90B reading a program from the ROM 90C onto the RAM 90D and executing it.

[0133] The programs for executing the above-described processes performed by the information processing device 10 and information processing device 11 in the above-described embodiment may be stored in the HDD90E. Alternatively, the programs for executing the above-described processes performed by the information processing device 10 and information processing device 11 in the above-described embodiment may be pre-installed and provided in the ROM90C.

[0134] Furthermore, the programs for executing the above-described processes performed by the information processing devices 10 and 11 of the above-described embodiment 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. Alternatively, the programs for executing the above-described processes performed by the information processing devices 10 and 11 of the above-described embodiment may be stored on a computer connected to a network such as the Internet and provided by allowing download via the network. Alternatively, the programs for executing the above-described processes performed by the information processing devices 10 and 11 of the above-described embodiment may be provided or distributed via a network such as the Internet.

[0135] Although embodiments of the present invention have been described above, these embodiments are presented as examples only and are not intended to limit the scope of the invention. This novel embodiment can be implemented 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 variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. [Explanation of Symbols]

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

Claims

1. An extraction unit that extracts first file path information representing the file path in the file to be inspected, which is used for vulnerability testing of the target of the vulnerability testing tool, A registration unit registers the first file path information and the second file path information, which represents the file path to the file copied from the object to be inspected using the first file path information, in the second management information. An information processing device equipped with the following features.

2. The aforementioned registration unit is The file copied from the object to be inspected using the first file path information is stored in the file storage unit. The second file path information represents the file path to the file in the file storage unit. The information processing apparatus according to claim 1.

3. The extraction unit is The extracted first file path information is registered in the first management information. The aforementioned registration unit is Using the first file path information registered in the first management information, the file is copied from the object to be inspected to the file storage unit. The second file path information, which represents the file path to the file in the file storage unit, and the first file path information are associated and registered in the second management information. The information processing apparatus according to claim 2.

4. The extraction unit is The vulnerability testing tool extracts the first file path information based on the vulnerability testing method information used for testing the vulnerability of the target of testing. The information processing apparatus according to claim 1.

5. The extraction unit is Based on the access log containing the file paths of the files accessed by the vulnerability testing tool when it performed the vulnerability testing on the target, and the excluded file information which specifies files not to be used for vulnerability testing, the file paths recorded in the access log that access files other than those specified in the excluded file information are extracted as the first file path information. The information processing apparatus according to claim 1.

6. A construction unit 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 associated with the first file path information. The information processing apparatus according to claim 1, comprising:

7. An information processing method performed by an information processing device, A step of extracting first file path information representing the file path in the file to be inspected, which is used for vulnerability testing of the target of the vulnerability testing tool, The steps include registering the second file path information, which represents the file path to the file copied from the inspection target using the first file path information, in association with the first file path information and registering it in the second management information, Information processing methods including

8. A step of extracting first file path information representing the file path in the file to be inspected, which is used for vulnerability testing of the target of the vulnerability testing tool, The steps include registering the second file path information, which represents the file path to the file copied from the inspection target using the first file path information, in association with the first file path information and registering it in the second management information, An information processing program that causes a computer to execute something.

Images