JPWO2020136793A1 - Information processing equipment, information processing methods and information processing programs - Google Patents

Abstract

The variable determination unit (22) determines the type of each of the plurality of variables included in the program executed by the device. The candidate generation unit (23) compares each type of the plurality of variables determined by the variable determination unit (22) with each type of the plurality of information assets used by the device, and compares each type of the plurality of information assets with each of the plurality of information assets. Generate one or more candidates for correspondence with each of a plurality of variables.

Description

The present invention relates to vulnerability analysis.

In the development process that considers security, security analysis and examination are conducted from the upstream stage of development in order to prevent the creation of vulnerabilities, which are security problems. First, in the upstream phase of development such as system design, threat analysis is conducted to identify threats that should not occur in the system to be developed (for example, threats such as eavesdropping of confidential information flowing through the communication path are identified. ). Then, based on the results of the threat analysis, consider the policy of measures to prevent the threat (for example, it is necessary to encrypt the communication path). As the development phase progresses to the design and implementation stages, the processing content for realizing the system to be developed and the security functions and operation methods suitable for the specific implementation method of the program that realizes the processing content will be examined. Then, the examination results are incorporated into the design and implementation. At the final stage of design and implementation, analysis is performed to confirm whether the designed and implemented program is vulnerable.

As one of the methods for realizing a vulnerability analyzer for confirming whether or not there is a vulnerability, there is a technique for statically analyzing the specifications of a designed and implemented program or the program itself.
The conventional vulnerability analyzer analyzes the source code of the program by using an analysis technique such as pollution analysis according to a predetermined rule (for example, Patent Document 1).
In addition, a method has been proposed in which the specifications of a program are formally described by a model, and a formal method called model checking is used to mathematically prove whether the behavior of the program satisfies the property of causing a vulnerability (for example). , Patent Document 2).

Japanese Patent No. 5740702 Japanese Unexamined Patent Publication No. 2008-262311

In the method of Patent Document 1, the source code of the program is analyzed according to a predetermined rule. For this reason, it is not possible to confirm vulnerabilities caused by omissions or errors in the design and implementation of security measures examined after the threat analysis conducted in the upstream process.
Further, in the method of Patent Document 2, verification is possible by defining or selecting the property of the object to be proved. In order to correctly define or select the nature of the object to be proved, it is necessary to understand the details of what the design and implementation specifications should be. However, threat analysis is carried out in the upstream phase of development, where design and implementation specifications are uncertain. Therefore, it is very troublesome to define or select the property of the object to be proved by associating the result of the threat analysis with the specification in which the program is designed and implemented. Further, in the method of statically analyzing the specifications of a program, if the entire program is analyzed, a large amount of computer resources such as memory are required and the calculation time becomes long.

In order to perform vulnerability analysis efficiently, the relationship between the part in the program (program executed by the device) that incorporates security measures after threat analysis in the upstream process and the information assets used by the device, and It is useful to clarify the relationship between device information assets and vulnerabilities.
From this point of view, it is a main object of the present invention to contribute to clarifying the correspondence between the part in the program, the information asset, and the vulnerability.

The information processing device according to the present invention is
A variable discriminator that discriminates each type of multiple variables included in the program executed by the device,
Each type of the plurality of variables determined by the variable discriminating unit is compared with each type of the plurality of information assets used by the device, and each of the plurality of information assets and each of the plurality of variables It has a candidate generation unit that generates one or more candidates of the correspondence relationship of.

According to the present invention, in order to generate candidates for the correspondence between the variables included in the program executed by the device and the information assets used by the device, the correspondence between the part in the program, the information assets and the vulnerability is clarified. Can contribute to.

The figure which shows the configuration example of the vulnerability analyzer which concerns on Embodiment 1. FIG. The flowchart which shows the operation example of the vulnerability analyzer which concerns on Embodiment 1. The figure which shows the example of the information asset flow about the controller which concerns on Embodiment 1. FIG. The figure which shows the example of the program specification which concerns on Embodiment 1. FIG. The figure which shows the example of the correspondence relationship between the component element and a program specification which concerns on Embodiment 1. FIG. The figure which shows the example of the threat analysis result which concerns on Embodiment 1. FIG. The flowchart which shows the operation example of the variable discriminating part which concerns on Embodiment 1. The figure which shows the example of the processing type DB which concerns on Embodiment 1. FIG. The figure which shows the example of the program variable processing relation which concerns on Embodiment 1. FIG. The figure which shows the example of the information asset-variable correspondence relationship candidate which concerns on Embodiment 1. FIG. The figure which shows the example of the extraction operation of the related threat list which concerns on Embodiment 1. FIG. The figure which shows the example of the related threat list which concerns on Embodiment 1. FIG. The figure which shows the example of the threat-vulnerable type correspondence DB which concerns on Embodiment 1. FIG. The figure which shows the example of the vulnerability type candidate which concerns on Embodiment 1. FIG. The figure which shows the example of the vulnerability detection result which concerns on Embodiment 1. FIG. The figure which shows the configuration example of the vulnerability analyzer which concerns on Embodiment 2.

Hereinafter, embodiments of the present invention will be described with reference to the drawings. In the following description and drawings of the embodiments, those having the same reference numerals indicate the same parts or corresponding parts.

Embodiment 1.
*** Explanation of configuration ***
The configuration of the vulnerability analyzer 10 according to the first embodiment will be described with reference to FIG.
The vulnerability analyzer 10 corresponds to an information processing device.

The vulnerability analyzer 10 is a computer. The vulnerability analyzer 10 includes hardware such as a processor 11, a memory 12, a storage 13, and a communication interface 14. The proprocessor 11 is connected to other hardware via a signal line, and the processor 11 controls these other hardware.

The processor 11 is an IC (Integrated Circuit) that performs processing. Specific examples of the processor 11 are a CPU (Central Processing Unit), a DSP (Digital Signal Processor), and a GPU (Graphics Processing Unit). In FIG. 1, only one processor 11 is shown. However, the number of processors 11 may be plural, and the plurality of processors 11 may execute programs that realize each function in cooperation with each other.

The memory 12 is a storage device that temporarily stores data for processing of the processor 11. Specific examples of the memory 12 are SRAM (Static Random Access Memory) and DRAM (Dynamic Random Access Memory).

The storage 13 is a storage device for storing data. As a specific example, the storage 13 is an HDD (Hard Disk Drive). Further, the storage 13 may be an SSD (Solid State Drive). The storage 13 includes SD (registered trademark, Secure Digital) memory card, CF (CompactFlash, registered trademark), NAND flash, flexible disk, optical disk, compact disc, Blu-ray (registered trademark) disk, DVD (Digital Versaille Disk), and the like. It may be a portable recording medium.

The communication interface 14 is an interface for communicating with an external device. As a specific example, the communication interface 14 is a port of Ethernet (registered trademark), USB (Universal Serial Bus), HDMI (registered trademark, High-Definition Multimedia Interface).

The vulnerability analyzer 10 has, as functional components, a first reception unit 21, a variable discrimination unit 22, a candidate generation unit 23, a second reception unit 24, a related threat extraction unit 25, a vulnerability candidate extraction unit 26, and a vulnerability. A sex analysis unit 27 is provided. The second reception unit 24 corresponds to an output unit.
The functions of each functional component of the vulnerability analyzer 10 are realized by a program.

A program that realizes the functions of each functional component of the vulnerability analyzer 10 is stored in the storage 13. This program is read into the memory 12 by the processor 11 and executed by the processor 11. As a result, the functions of each functional component of the vulnerability analyzer 10 are realized.

The function of each functional component of the vulnerability analyzer 10 may read information that determines the operation of analysis performed by the program and information that determines the condition of determination from a database or a setting file stored in the storage 13. Further, the information that determines the operation of the analysis and the information that determines the condition of the judgment may be part of the program. For example, in the present embodiment, the variable determination unit 22 reads the processing type DB 31 and changes the analysis operation. In addition, the vulnerability candidate extraction unit 26 reads the threat-vulnerability response DB 32 and changes the analysis operation.

Note that FIG. 1 illustrates a configuration in which only one vulnerability analyzer 10 is used. Instead, a plurality of computers may be connected via a network, and the plurality of computers may work together to form a vulnerability analysis system.
Further, in FIG. 1, it is assumed that an input / output device for the user to input or output to the vulnerability analysis device 10 is connected via the communication interface 14. Instead of this, the vulnerability analysis device 10 may be provided with an interface for inputting and outputting, so that the user can directly operate the vulnerability analysis device 10.

*** Explanation of operation ***
The operation of the vulnerability analyzer 10 according to the first embodiment will be described with reference to FIGS. 2 to 15. The operation of the vulnerability analyzer 10 shown below corresponds to an information processing method and an information processing program.

FIG. 2 is a flowchart showing the overall operation of the vulnerability analyzer 10 according to the first embodiment.

First, the first reception unit 21 receives input of various information necessary for analysis (step S1).
In step S1, the first reception unit 21 includes an information asset flow 41 (FIG. 3), a program specification 42 (FIG. 4), a correspondence relationship between a component and a program specification 43 (FIG. 5), and a threat analysis result 44 (FIG. 5), which will be described later. Accept Fig. 6).

Further, the variable determination unit 22 extracts the variables included in the program represented by the program specification 42, and determines the type of the extracted variables (step S2).
As will be described later, the program specification 42 includes a program (source code) executed by the device to be developed, information describing the characteristics of the program (flow chart, UML (Unified Modeling Language), SysML activity diagram, sequence diagram, etc. ).
The variable determination unit 22 determines whether the extracted variable is an input variable, an output variable, or an internally used variable as the type of the extracted variable.

Next, the candidate generation unit 23 generates a candidate for the correspondence between the information asset and the variable (step S3).
The candidate generation unit 23 compares the type of the variable determined by the variable determination unit 22 with the type of the information asset used by the device, and generates one or more candidates for the correspondence between the information asset and the variable.
The information asset is the information determined to be used by the component (equipment) by the threat analysis in the present specification. Specifically, the information assets of the constituent elements (equipment) are described in the information asset flow 41 (FIG. 3).
The types of information assets include input information assets, which are information assets input to the device, output information assets, which are information assets output from the device to the outside of the device, and internal use, which is information assets used inside the device. There are information assets.
The candidate generation unit 23 generates a correspondence candidate by associating an input information asset with an input variable, an output information asset with an output variable, and an internal use information asset with an internal use variable.

When there are a plurality of correspondence relationship candidates, the second reception unit 24 outputs a plurality of correspondence relationship candidates. Then, the second reception unit 24 accepts the selection of the correspondence relationship by the user of the vulnerability analysis device 10 (step S4).
That is, the second reception unit 24 displays a plurality of correspondence relationship candidates, for example, on the input / output device, and the user of the vulnerability analysis device 10 displays the corresponding correspondence relationship from among the displayed correspondence relationship candidates. Select. Then, the second reception unit 24 accepts the selection from the user.

Next, the related threat extraction unit 25 extracts related threats based on the correspondence between the information assets and the variables (step S5).
That is, when only one correspondence relationship candidate is generated in step S3, the related threat extraction unit 25 extracts the related threat based on only one correspondence relationship candidate generated. On the other hand, when a plurality of correspondence relationship candidates are generated in step S3 and the selection of the correspondence relationship in step S4 is accepted, the related threat is extracted based on the correspondence relationship selected in step S4.
Specifically, the related threat extraction unit 25 extracts related threats from the threat analysis result 44 (FIG. 6) received in step S1.

Next, the vulnerability candidate extraction unit 26 extracts candidates for the type of vulnerability that may be used in an attack leading to a related threat (step S6).

Finally, the vulnerability analysis unit 27 performs a vulnerability analysis for investigating whether a candidate for the type of vulnerability can occur in the description of the program specification 42, and outputs the analysis result (step S7).

Next, the operation of each step in FIG. 2 will be sequentially described.

(Step S1: First reception process in FIG. 2)
The first reception unit 21 has an information asset flow 41 (FIG. 3), a program specification 42 (FIG. 4), a correspondence relationship between components and program specifications 43 (FIG. 5), and a threat analysis result 44 (FIG. 6). And accept.

Specifically, the input / output device connected via the communication interface 14 is operated by the user. By the operation of the user, the information asset flow 41, the program specification 42, the correspondence relationship 43 between the component and the program specification, and the threat analysis result 44 are input. Then, the first reception unit 21 receives the information asset flow 41 input via the communication interface 14, the program specification 42, the correspondence relationship 43 between the component and the program specification, and the threat analysis result 44.
Further, the first reception unit 21 writes the information asset flow 41, the program specification 42, the correspondence relationship 43 between the component and the program specification, and the threat analysis result 44 into the memory 12, respectively.

An example of the information asset flow 41 will be described with reference to FIG.

The information asset flow 41 is obtained by organizing the flow of information assets after the threat analysis is performed. The information asset flow 41 is generated for each device included in the development target system.
The information asset flow 41 includes a component 411 that is a component (equipment) constituting the system to be developed, a related element 412 that is a component (equipment) related to the component 411, and a component 411 and a related element 412. The connection relationship 413 with the information asset, the name 414 of the information asset, and the type 415 of the information asset are included.
As described above, the types of information assets are input information assets, output information assets, and internal use information assets. There may be types of information assets other than input information assets, output information assets, and internal use information assets.
The “input” is a flow of information assets input to the component 411 from the outside of the component 411. The “output” is a flow of information assets output from the component 411 to the outside of the component 411. “Internal use” is a flow of information assets used only inside the component 411.

Specifically, the information asset flow 41 can be represented by a diagram as if the UML communication diagram is expanded, as shown in FIG. In FIG. 3, the rectangle represents the component 411 or the related element 412. The component 411 is a "controller" in the example of FIG. Further, the related elements 412 are "HMI" and "device" in the example of FIG.
The connection relationship 413 is represented by a solid line connecting the component 411 and the related element 412.
Further, in FIG. 3, an arrow is shown near the connection relationship 413. These arrows represent the flow of information assets. The direction of the arrow indicates the direction of the flow of information assets.
In addition, a line having a round starting point extends from the controller regardless of the connection relationship 413. This line also represents the flow of information assets. This line indicates that there is no flow between the component 411 and the related element 412, that is, it is an internal use information asset.
The character string arranged near the line of the flow of the information asset is the name 414 of the information asset handled in the flow. The character string enclosed in <<>> is the type 415 of the information asset. For example, the arrow from the HMI to the controller in FIG. 3 means that the information asset "command" flows from the "HMI" to the "controller". Then, the arrow indicates that the type 415 of the information asset is "input" (input information asset) from the standpoint of the "controller". In addition, the line with a circle starting point extending from the "controller" means that the type 415 of the information asset "MAC key" is "internal use" (internal use information asset), that is, the information asset "MAC key" is inside the controller. Indicates that it will be used in.
The information asset flow 41 corresponds to information asset information.

Next, an example of the program specification 42 will be described with reference to FIG.

The program specification 42 includes the name 421 of the program to be analyzed for vulnerability and the program processing content 422 expressing the flow of variables (data flow) and the flow of processing (control flow).
Specifically, the program specification 42 contains logic that is the entire program or a part thereof that is executed by the device (corresponding to the component 411 in FIG. 3) included in the development target system after the threat analysis is performed. Will be described. The program specification 42 is described for each device included in the development target system.
Further, for some devices and programs that are not subject to vulnerability analysis, the program specification 42 does not have to be input to the vulnerability analysis device 10.

Specifically, the program specification 42 is a source code or a program model.
The program model is information that can describe the structure and operation of a program such as a flowchart, UML, and SysML in a chart. The program model is, for example, a flowchart in which a source code written in a program language and processing / judgment are described in a program language format such as C language (m = n + 1 or m = add (n, 1), etc.). The program model also corresponds to an activity diagram or sequence diagram of UML or SysML, a block diagram used in DFD, control engineering, and the like. The program model is described and stored in a data format capable of expressing a hierarchical structure so that the processor 11 (variable determination unit 22) can process its contents. The program model is described in a data format such as XML (Extension Markup Language) and JSON (Javascript® Object Notification), for example. For example, FIG. 4 shows an example of a program specification 42 relating to communication processing of the component “controller” with the HMI. In FIG. 4, a part of the operation contents of the program running on the controller is described in the form of a general C language source code.
Further, the program name 421 is "PROGRAM_CC", and the program processing content 422 is a description content in C language. In the example of FIG. 4, the program name 421 is indicated by the file name of the C language source code, but any format can be used as long as the information can uniquely identify each program specification 42 by the vulnerability analyzer 10. good. The program name 421 is used in the correspondence relationship 43 between the component elements and the program specifications, which will be described later.

Next, an example of the correspondence 43 between the components and the program specifications will be described with reference to FIG.

Correspondence relationship 43 between the component and the program specification shows the correspondence relationship between the component 431 to be the target of the vulnerability analysis and the program specification 432.
The correspondence 43 between the components and the program specifications can be expressed as, for example, a table as shown in FIG. In FIG. 5, there are two program specifications 42 to be inspected by the component “controller”, which are “PROGRAM_CC” and “PROGRAM_DC”, respectively.

Next, an example of the threat analysis result 44 will be described with reference to FIG.

The threat analysis result 44 shows the result of the threat analysis for the system to be developed.
The threat analysis result 44 includes threat 441, component 442, related information assets 443, and threat type 444.
The content of the threat is shown in the threat 441.
The component 442 indicates the component or the connection relationship in which the threat occurs.
The related information asset 443 indicates the information asset related to the threat.
The threat type 444 indicates the type of impact on the information asset when a threat occurs. The threat type 444 indicates, for example, one of C, I, and A generally used to indicate an attribute of information security. Note that C means confidentiality, I means integrity, and A means availability.
The threat analysis result 44 can be represented in the form of a table as shown in FIG. 6, for example. In the example of FIG. 6, in the record of the first line, "leakage by guessing" is shown as threat 441, and "remote terminal" which is a component in which the threat occurs is shown as component 442, and related information assets. As 443, the "password" related to the leakage of the guess is shown, and as the threat type 444, "C" is shown.

(Step S2 in FIG. 2: Program variable processing-related analysis processing)
The variable determination unit 22 determines the type of the variable based on the process in which the variable included in the program specification 42 accepted in step S1 is used, and analyzes the propagation relationship between the variables and the order of the processes.
More specifically, the variable determination unit 22 determines whether the process in which the variable is used is an input process, an output process, or an internal use process. The input process is a process of inputting a value from the outside of the device. The output process is a process of outputting a value to the outside of the device. The internal use process is a process of using a value inside the device. The variable determination unit 22 determines the type of variable based on the type of processing.
The propagation relationship between variables is the propagation relationship of values between variables within the program.

FIG. 7 is a flowchart illustrating an operation example of the variable determination unit 22.

First, the variable determination unit 22 reads various information necessary for analysis from the memory 12 (step S21).

Next, the variable determination unit 22 extracts the variables included in the program specification 42 (step S22).

Next, the variable determination unit 22 determines the type of the extracted variable (step S23).

Next, the variable determination unit 22 analyzes the propagation relationship and the processing order of each variable whose type can be determined (step S24).

Finally, the variable determination unit 22 writes the analysis result into the memory 12 (step S25).

Next, the details of steps S21 to S26 of FIG. 7 will be described.

<Details of step S21 in FIG. 7>
In step S21, the variable determination unit 22 reads the processing type DB 31 from the storage 13 and writes the processing type DB 31 to the memory 12.
Next, the variable determination unit 22 reads the information of the program specification 42 and the processing type DB 31 from the memory 12.
Here, the program specification 42 is the program specification 42 accepted in step S1.

An example of the processing type DB 31 will be described with reference to FIG.

The process type DB 31 includes a process name 311 and a process type 312.
The process name 311 indicates the name of the process included in the program specification 42.
The process type 312 indicates which of the input process, the output process, and the internal use process (security process) corresponds to the process indicated by the process name 311. In FIG. 8, the input process is described as Input. The output process is described as Output. The internal use process (security process) is described as Security.
The process shown in the process name 311 is a function, a method, or the like.
In the example of FIG. 8, for example, the processing type of the processing name receiveMessage is input processing (Input).

<Details of step S22 in FIG. 7>
In step S22, the variable determination unit 22 extracts variables from the program specification 42 read in step S21. The variable extraction process differs depending on the description method of the program specification 42.
In the program specification 42 (source code) used in the description in this embodiment, variables can be extracted by using the lexical analysis and parsing techniques used in the compiler. Even in the case of description other than the source code, the variable determination unit 22 extracts variables according to the respective description rules.

<Details of step S23 in FIG. 7>
In step S23, the variable determination unit 22 determines the type of each variable extracted in step S22.
The variable determination unit 22 checks whether or not each of the extracted variables is used for processing the function, method, or the like shown in the processing name 311 of the processing type DB31. "Used for processing" means that a variable is used as an argument of a function or method, or a variable is used as a return value of a function or method.
When the extracted variable is used for the process indicated by the process name 311, the variable determination unit 22 determines the variable type according to the process type 312 of the target process. As described above, the variable determination unit 22 determines the type of the variable based on the type of processing.
More specifically, for example, when the program specification 42 is described in C language and the processing type is "Input", the variable determination unit 22 is an argument for passing a return value or an address (argument passed by reference). The variables used in (including) are judged to be "input variables". On the other hand, if the processing type is "Autoput", the variable determination unit 22 determines that the variable used in the argument passed by value is an "output variable". Further, the variable discriminating unit 22 discriminates the variable used in the argument of passing the address into both the “input variable” and the “output variable”. Further, the variable determination unit 22 determines that the variable used for the return value is an “input variable”. Further, the variable discriminating unit 22 is a variable that is not discriminated into any type as a result of performing the above-mentioned determination for all the variables, and the variable used in the conditional statement and the processing type are "Securty". The variable used for the argument or return value of the function of is determined to be an "internally used variable".

For example, when the program specification 42 shown in FIG. 4 is analyzed by the above-mentioned determination rule using the processing type DB 31 shown in FIG. 8, msg and len become “input variables”. In addition, dev, val, and ret become "output variables". In addition, key and state become "internal use variables". Further, cmd is not classified into any of them.

Although it does not exist in the example of FIG. 4, if two or more of the same variables can be identified as different types, each variable is treated separately. For example, when the same variable msg can be determined to be a different variable type at a place different from the place where the variable msg is determined to be an input variable, the variable determination unit 22 treats each as a different variable. Further, the variable determination unit 22 makes it possible to distinguish even the same variable name. The variable determination unit 22 makes it possible to uniquely identify each variable in the form of variable name: line number or the like, for example, msg: 12.

Further, in the above, in step S23, an example in which the variable determination unit 22 determines the processing type of the variable using the information of the processing type DB 31 has been described. The processing type may be determined based on the rules generated in advance in this way, or may be determined by the logic set in the variable determination unit 22.

Further, in the above, in the process of determining the type of the variable, the "input variable" or the "output variable" is determined depending on how the variable is handled by the function or the processing type assigned in advance to the function. Further, in the above, a variable satisfying a certain condition is determined as an "internal use variable". However, another rule may be used as a rule for determining the type of variable.
Further, in the present embodiment, it is assumed that the above-mentioned determination rule is held inside the variable determination unit 22, but the determination rule may be held in a file or a database. Moreover, you may change the judgment rule.

<Details of step S24 in FIG. 7>
In step S24, the variable determination unit 22 analyzes the propagation relationship and the processing order of each variable whose type can be determined in step S23. The propagation relationship is a data flow in which the value of a variable determined as an "input variable" propagates to another variable. The variable determination unit 22 can analyze the propagation relationship from the variable assignment relationship and the like as in the existing static code analysis.
For example, when the processing type DB 31 shown in FIG. 8 is used for the program specification 42 shown in FIG. 4, the variable determination unit 22 obtains the propagation relationship 453 of FIG.

<Details of step S25 in FIG. 7>
In step S25, the variable determination unit 22 writes the results of the analysis in steps S21 to S24 into the memory 12 as a program variable processing relationship 45 (FIG. 9).

An example of the program variable processing relationship 45 will be described with reference to FIG.

The program variable processing relationship 45 represents the analysis result of the variable determination unit 22 for the variables in the program specification 42.
The program variable processing relationship 45 includes a variable type 451, a variable name 452, and a propagation relationship 453.
The variable type 451 indicates the type of the variable obtained by the analysis of the variable discrimination unit 22.
The variable name 452 indicates the name of the variable.
As described above, the propagation relationship 453 indicates a data flow (propagation relationship) in which the value of the variable determined as the “input variable” is propagated to another variable.
In the example shown in FIG. 9, the variable type of the variable name msg is “input variable”. Further, from the propagation relationship 453, the variable name msg propagates to the output variables dev and val.

(Step S3 in FIG. 2: Information asset-variable correspondence guessing process)
The candidate generation unit 23 generates candidates for the correspondence between the information asset and the variable based on the information asset flow 41 input in step S1 and the program variable processing relationship 45 obtained in step S2.

Specifically, the candidate generation unit 23 reads the information asset flow 41 and the program variable processing relationship 45 from the memory 12.
Next, the candidate generation unit 23 maps the “input” of the information asset flow 41 and the “input variable” of the program variable processing relationship 45. Similarly, the candidate generation unit 23 maps the “output” of the information asset flow 41 and the “output variable” of the program variable processing relationship 45. Further, the candidate generation unit 23 maps the “internal use” of the information asset flow 41 and the “internal use variable” of the program variable processing relationship 45. In this way, the candidate generation unit 23 generates all the combinations of the information assets and the variables of the program specification 42.
Then, the candidate generation unit 23 writes the generated correspondence candidate as the information asset-variable correspondence candidate 46 in the memory 12.

An example of the information asset-variable correspondence candidate 46 will be described with reference to FIG.

The information asset-variable correspondence candidate 46 includes a candidate name 461, an input or internal use information asset 462, a variable name 463, a propagation relationship 464, and an output information asset 465.
In the example of FIG. 10, in candidate 1, the command, which is an input information asset, is associated with the variables len and msg. Further, the value which is the input information asset is associated with the variable ans. Further, the MAC key, which is an information asset for internal use, is associated with the variable key. Further, the instruction which is an output information asset is associated with the variables dev and val. Further, the response, which is an output information asset, is associated with the variable ret.
The plurality of candidates shown in the information asset-variable correspondence candidate 46 are different from each other.

(Step S4 in FIG. 2: Second reception process)
When there are a plurality of correspondence candidate candidates in the information asset-variable correspondence candidate 46 (FIG. 10) generated in step S3, the second reception unit 24 outputs the information asset-variable correspondence candidate 46.
Then, the second reception unit 24 accepts the selection of the correspondence between the information asset and the variable selected by the user.

Specifically, the second reception unit 24 reads the information asset-variable correspondence candidate 46 from the memory 12. When there are a plurality of correspondence candidates in the information asset-variable correspondence candidate 46, the second reception unit 24 connects the information asset-variable correspondence candidate 46 to the information asset-variable correspondence candidate 46 via the communication interface 14. Send to the output device.
Then, the information asset-variable correspondence candidate 46 is displayed on the input / output device. The user operates the input / output device and selects the information asset-variable correspondence 47 from the information asset-variable correspondence candidate 46. The selected information asset-variable correspondence 47 is input to the second reception unit 24 via the communication interface 14. Then, the second reception unit 24 receives the information asset-variable correspondence 47 input via the communication interface 14. Further, the second reception unit 24 writes the received information asset-variable correspondence 47 into the memory 12. The information asset-variable correspondence 47 is one of the correspondence candidates included in the information asset-variable correspondence candidate 46, which shows the correspondence between the actual information asset and the variable.
As shown in FIG. 10, the information asset-variable correspondence candidate 46 also includes a propagation relationship and a processing order. Therefore, the user can select the information asset-variable correspondence 47 in consideration of the propagation relationship and the processing order.
Here, it is assumed that candidate 1 in FIG. 10 is selected as the information asset-variable correspondence 47.
If there is only one correspondence candidate in the information asset-variable correspondence candidate 46, step S4 is not performed, but the correspondence candidate included in the information asset-variable correspondence candidate 46 is also as follows. Then, it is referred to as an information asset-variable correspondence 47.

(Step S5 in FIG. 2: Related threat extraction process)
The related threat extraction unit 25 extracts a list of threats related to the program specification 42 as a related threat list 48 based on the information asset-variable correspondence relationship 47. The related threat list 48 is extracted for each program specification 42.

Specifically, the related threat extraction unit 25 reads the threat analysis result 44 (FIG. 6) and the correspondence relationship 43 (FIG. 5) between the components and the program specifications from the memory 12.
Then, the related threat extraction unit 25 processes each entry of the correspondence 43 of the component and the program specification in order, and sets the information asset flow 41 (FIG. 3) corresponding to the content of the component 431 and the content of the program specification 432. Read the corresponding information asset-variable correspondence 47 from the memory.
Then, the related threat extraction unit 25 extracts the threat related to the program specification 42 from the threat analysis result 44 (FIG. 6) by using the information asset flow 41 and the information asset-variable correspondence 47 (details are shown in FIG. 11 will be used later).
Then, the related threat extraction unit 25 writes the extracted result as the related threat list 48 in the memory 12 in association with the processed program specification 42. The related threat extraction unit 25 performs these operations for all the entries in the correspondence relationship 43 (FIG. 5) between the component and the program specification.

The related threat extraction unit 25 extracts related threats by the operation shown in FIG. 11, for example.

First, the related threat extraction unit 25 searches the threat analysis result 44 (FIG. 6) for an entry in which the description content of the component 431 of the component and the program specification correspondence 43 (FIG. 5) is included in the component 442. .. Then, the related threat extraction unit 25 tentatively extracts the description content of the threat 441 of the entry obtained by the search.
For example, PROGRAM_C. When threat extraction is performed for C, according to the correspondence relationship 43 (FIG. 5) between the components and the program specifications, PROGRAM_C. The component on which C operates is the controller. Therefore, the related threat extraction unit 25 searches the threat analysis result 44 (FIG. 6) for an entry in which the component 442 includes the “controller”. In the threat analysis result 44 (FIG. 6), entries for "HMI-controller", "controller" and "controller-device" are obtained (procedure (1) in FIG. 11). Then, the related threat extraction unit 25 tentatively extracts "tampering with unencrypted communication", "leakage by guessing", "tampering by retransmission", and "DoS by retransmission" described in threat 441 of these entries (FIG. 11). Procedure (2)).

Next, when the description content of the information asset 443 related to the entry obtained by the search is associated with the variable in the information asset-variable correspondence 47, the related threat extraction unit 25 determines the threat 441 of the corresponding entry. Formally extract the contents of.
The related threat extraction unit 25 has a "command", "response", "MAC key", "instruction", of the related information asset 443 of the entry (line numbers 4 to 13) obtained in the procedure (1) of FIG. It is determined whether or not each of the "value" and the "status" is associated with the variable in the information asset-variable correspondence 47 (FIG. 10).
In the information asset-variable correspondence 47 of FIG. 10, information assets other than "status" are associated with variables.
Therefore, the related threat extraction unit 25 formally extracts the description contents of the threat 441 on the 4th to 11th lines of FIG. 11 (procedure (3) of FIG. 11).
Then, the related threat extraction unit 25 writes the description content of the extracted threat 441 into the memory 12 as the related threat list 48.

Further, an example of the related threat list 48 will be described with reference to FIG.

The related threat list 48 is a part of the threat analysis result 44 extracted by the extraction process illustrated in FIG. The related threat list 48 is stored in association with the related program specification 42 (FIG. 4). Further, the related threat list 48 may be associated with the entry of the correspondence relationship 43 (FIG. 5) between the component and the program specification.

(Step S6 of FIG. 2: Related vulnerability candidate extraction process)
Based on the information in the related threat list 48 (FIG. 12) extracted in step S5 and the threat-vulnerable type response DB 32 (FIG. 13), the vulnerability candidate extraction unit 26 makes the corresponding program specification 42 (FIG. 4). Vulnerability type candidates 49 to be inspected that may be used in attacks of related threats are extracted for each related threat.

Specifically, the vulnerability candidate extraction unit 26 reads the threat-vulnerable type response DB 32 from the storage 13 and writes the threat-vulnerable type response DB 32 to the memory 12.
Next, the vulnerability candidate extraction unit 26 reads the correspondence 43 (FIG. 5) between the components and the program specifications from the memory 12.
Then, the vulnerability candidate extraction unit 26 sequentially processes each entry of the correspondence relationship 43 (FIG. 5) between the component and the program specification, and reads the related threat list 48 (FIG. 12) corresponding to the program specification 432 from the memory 12. ..
Next, the vulnerability candidate extraction unit 26 refers to the entry of the threat-vulnerable type response DB 32 for each threat described in the related threat list 48, and selects the candidate for the vulnerability type related to the threat in the vulnerability type list. Obtained from 322. Then, the vulnerability candidate extraction unit 26 writes the acquired vulnerability type candidate as the vulnerability type candidate 49 (FIG. 14) in the memory 12 in association with each threat. The vulnerability candidate extraction unit 26 does this for all threats.
Then, the vulnerability candidate extraction unit 26 continues processing in the same manner for the next entry of the correspondence relationship 43 (FIG. 5) between the component and the program specification, and extracts the vulnerability type candidate 49 for all the entries. ..

An example of the threat-vulnerable type response DB 32 will be described with reference to FIG.

The threat-vulnerable type response DB 32 can be represented in the form of a table as shown in FIG.
The threat-vulnerable type response DB 32 includes information on the threat 321 and the list of vulnerability types 322 corresponding to the threat.
The vulnerability type list 322 lists the vulnerability types corresponding to the threat. If there is no threat entry in the threat-vulnerable type response DB 32, or if there is a threat entry but there is no description of the corresponding vulnerability type, the threat is described in the program specification 42. There is no vulnerability type that can be analyzed at the level. For example, "Failure" in FIG. 13 has no vulnerability type, because the failure is a device failure, not a program-induced vulnerability. When there is no such vulnerability, the vulnerability candidate extraction unit 26 includes a display indicating that there is no candidate for a vulnerability corresponding to the threat in the output of the result of the vulnerability analysis in step S7 described later. May be good.

An example of the vulnerability type candidate 49 will be described with reference to FIG.

The vulnerability type candidate 49 corresponds to the threat 441 of the related threat list 48, the component 442, the related information asset 443, the threat type 444, and the vulnerability type list 322 of the threat-vulnerable type response DB 32. This is the attached information. Unlike FIG. 14, the vulnerability type candidate 49 may be composed of only the threat 441, the related information asset 443, and the vulnerability type list 322. Further, the vulnerability type candidate 49 may include an element not shown in FIG.

(Step S7 in FIG. 2: Vulnerability analysis process)
The vulnerability analysis unit 27 analyzes whether the vulnerability type shown in the vulnerability type list 322 of the vulnerability type candidate 49 extracted in step S6 exists in the program specification 42. Then, the vulnerability analysis unit 27 outputs the analysis result.
Vulnerability analysis is performed using static code analysis or formal verification techniques as described in Background Techniques. The vulnerability analysis unit 27 inspects the vulnerabilities associated with each threat according to the information of the vulnerability type candidate 49.

Specifically, the vulnerability analysis unit 27 includes a program specification 42 (FIG. 4) for performing vulnerability analysis, a list of related threats 48 (FIG. 12), and a vulnerability type candidate 49 (FIG. 12) corresponding to each related threat. 14) and are read from the memory 12.
Next, the vulnerability analysis unit 27 performs a vulnerability analysis. That is, the vulnerability analysis unit 27 extracts the vulnerability type and the variables related thereto based on the corresponding related threat list 48 and the vulnerability type candidate 49, and performs the vulnerability analysis.
Then, when the vulnerability analysis unit 27 detects a vulnerability, the vulnerability detection result 410 (FIG. 15) is written to the memory 12 (if another vulnerability detection result 410 already exists, a new vulnerability is created). Add the sex detection result 410 to the existing vulnerability detection result 410).
The vulnerability analysis unit 27 performs this for all the program specifications 42 to be inspected.
When all the vulnerability analysis is completed for all the program specifications 42 to be inspected, the vulnerability analysis unit 27 sends the vulnerability detection result 410 to the connected input / output device via the communication interface 14. Send.
The input / output device that has received the vulnerability detection result 410 displays the vulnerability detection result 410. Further, the vulnerability detection result 410 may be saved in a file.
In addition, the vulnerability analysis unit 27 performs the vulnerability analysis in consideration of the variables associated with the information assets.

An example of the vulnerability detection result 410 will be described with reference to FIG.

The vulnerability detection result 410 includes the vulnerability type 411, the variable 412, the location 413, the threat 414, the component 415, and the information asset 416.
The vulnerability type 411 indicates the vulnerability type detected by the vulnerability analysis unit 27.
Variable 412 indicates a variable related to the vulnerability type detected by the vulnerability analysis unit 27.
The location 413 indicates a location in the program specification 42 related to the vulnerability type detected by the vulnerability analysis unit 27.
Threat 414 indicates a threat to the vulnerability type detected by the vulnerability analysis unit 27.
The component 415 indicates a component in which the vulnerability type detected by the vulnerability analysis unit 27 exists.
The information asset 416 indicates an information asset in which the vulnerability type detected by the vulnerability analysis unit 27 exists.
FIG. 15 shows PROGRAM_C. An example of the vulnerability detection result 410 related to C threat # 6 (threat by guessing) is shown. In the example of FIG. 15, "Vulnerability 1" is shown as the vulnerability type 411. Further, "key" is shown as the variable 412, "the first line of PROGRAM_CC" is shown as the location 413, and "leakage by guessing" is shown as the threat 414. Further, a "controller" is shown as a component 415, and a "MAC key" is shown as an information asset 416.

*** Explanation of the effect of the embodiment ***
As described above, according to the present embodiment, in order to generate candidates for the correspondence between the variables included in the program executed by the device and the information assets used by the device, the parts in the program, the information assets, and the vulnerabilities. Can clarify the correspondence with.

Further, in the present embodiment, the correspondence relationship between the threat analysis result and the program specification can be clarified based on the correspondence relationship between the flow of the information asset of the threat analysis and the input / output classification of the variable of the program specification. Therefore, according to this embodiment, the analysis target can be narrowed down at the time of vulnerability analysis.

Further, in the present embodiment, it is possible to analyze and infer the correspondence between the flow of information assets in the threat analysis and the input / output relationship of the variables of the program specifications. Therefore, according to the present embodiment, it is possible to save the user of the vulnerability analysis from having to execute them individually.

Further, in the present embodiment, the correspondence of the vulnerabilities used in the attacks linked to each threat is stored. Therefore, in the case of vulnerability analysis, it is possible to derive the vulnerability used in the attack by referring to the correspondence from the result of the threat analysis.

Embodiment 2.
In the first embodiment, the vulnerability analyzer 10 obtains the device configuration of the system to be analyzed for vulnerability analysis, the type of information asset, and the flow of information assets from the information asset flow 41 (FIG. 3) acquired from the outside.
In the present embodiment, an example in which the vulnerability analyzer 10 analyzes the device configuration of the system to be analyzed for vulnerability, the type of information asset, and the flow of information asset will be described.
In the present embodiment, the difference from the first embodiment will be mainly described.
The matters not explained below are the same as those in the first embodiment.

*** Explanation of configuration ***
The configuration of the vulnerability analyzer 10 according to the first embodiment will be described with reference to FIG.
In FIG. 16, an information asset determination unit 28 is added as compared with the configuration of FIG. The other elements shown in FIG. 16 are the same as those shown in FIG.

*** Explanation of operation ***
Hereinafter, an operation example of the vulnerability analyzer 10 according to the present embodiment will be described with reference to FIG.

In the present embodiment, in step S1 of FIG. 2, the first reception unit 21 receives the threat analysis input information 51 instead of the information asset flow 41.

Specifically, the input device connected via the communication interface 14 is operated by the user, and the threat analysis input information 51, the program specification 42, the correspondence between the components and the program specification 43, and the threat analysis result 44. Is entered.
Then, the first reception unit 21 receives the threat analysis input information 51, the program specification 42, the correspondence relationship 43 between the component and the program specification, and the threat analysis result 44 via the communication interface 14.
Further, the first reception unit 21 writes the threat analysis input information 51, the program specification 42, the correspondence relationship 43 between the component and the program specification, and the threat analysis result 44 into the memory 12.

The threat analysis input information 51 is information used for threat analysis.
The threat analysis input information 51 includes a plurality of components constituting the system to be analyzed for vulnerability analysis, connection relationships between the components, a list of information assets, and information indicating the flow of information assets.

Next, before carrying out step S3, the information asset determination unit 28 performs the related information asset flow extraction process.
In the related information asset flow extraction process, the information asset determination unit 28 determines the program specifications to be targeted for vulnerability analysis based on the threat analysis input information 51 received in step S1 and the correspondence relationship 43 between the components and the program specifications. The information asset flow related to 42 is extracted for each component. The information asset flow has the same format as the information asset flow 41 of FIG. 3 shown in the first embodiment.
That is, the information asset determination unit 28 determines whether each of the information assets used in the system subject to threat analysis is an input information asset, an output information asset, or an internal use information asset.

*** Explanation of the effect of the embodiment ***
As described above, according to the present embodiment, since the vulnerability analysis device 10 can generate the information asset flow, it is not necessary to generate the information asset flow by the external device.

Embodiment 3.
In the first and second embodiments, when the candidates for the correspondence between the information assets and the variables are output, the output order of the candidates is not taken into consideration.
In the present embodiment, the vulnerability analyzer 10 controls the output order according to the certainty of each candidate when outputting the candidate of the correspondence relationship between the information asset and the variable. That is, in the present embodiment, when the second reception unit 24 outputs a plurality of correspondence relationship candidates, a priority is set among the plurality of correspondence relation candidates, and the correspondence relation candidates having a high priority are set. Is given priority for output.
In the present embodiment, the difference from the first embodiment will be mainly described.
The matters not explained below are the same as those in the first embodiment.

Specifically, in step S3 of FIG. 2, when the candidate generation unit 23 analyzes the correspondence between the variable and the information asset in the program specification 42, the candidate generation unit 23 estimates the certainty as a candidate. The candidate generation unit 23 estimates the certainty of candidates for the correspondence between variables and information assets by, for example, a combination of keywords set in advance.
For example, the candidate generation unit 23 estimates that the information asset "command" and the variable command and the variable cmd are similar in notation, so that the certainty as a candidate is high. Further, the candidate generation unit 23 determines that a candidate having many combinations of corresponding variables has a high certainty. The candidate generation unit 23 specifies the output order (priority) of a plurality of correspondence candidates according to the certainty.
Then, the second reception unit 24 outputs a plurality of correspondence candidates according to the output order specified by the candidate generation unit 23.

As described above, in the present embodiment, the certainty of the correspondence candidate is estimated, the output order of the correspondence candidate is specified based on the certainty, and a plurality of correspondence candidates are selected in the specified output order. Output. Therefore, according to the present embodiment, the user can easily select the correct correspondence relationship even when there are a plurality of correspondence relationship candidates.

Embodiment 4.
In the first to third embodiments, the vulnerability candidate extraction unit 26 uses the threat-vulnerability response DB 32 to extract candidates for the vulnerability type corresponding to the related threat.
In the present embodiment, the first reception unit 21 acquires the attack tree. Then, the vulnerability candidate extraction unit 26 uses the attack tree to extract candidates for the type of vulnerability. The attack tree is information indicating a series of attack procedures for achieving each threat of the threat analysis result 44 (FIG. 6) and the types of vulnerabilities used in the attack procedure.
The vulnerability candidate extraction unit 26 is included in the attack tree instead of using the threat-vulnerability response DB 32 when extracting candidates for the type of vulnerability corresponding to each threat in the related threat list 48 (FIG. 12). Extract information on the type of vulnerability. The vulnerability candidate extraction unit 26 extracts the type of vulnerability from the attack tree after confirming that the attack destination is the corresponding component.
The matters not described in the present embodiment are the same as those in the first embodiment.

As described above, in this embodiment, flexible analysis can be performed by using the information on the type of vulnerability included in the attack tree (when the threat-vulnerable type response DB32 is used, the case of using the threat-vulnerable type response DB32). The correspondence between threat and vulnerability types is fixed). According to this embodiment, for example, when the type of vulnerability used changes depending on the system configuration and the attack method, flexible analysis can be performed.

Embodiment 5.
In the first to fourth embodiments, the program specification 42 is used as it is in the vulnerability analysis.
In this embodiment, the vulnerability analysis unit 27 performs a vulnerability analysis by referring to the association between information assets and variables and / and the type of threat. That is, in the present embodiment, the vulnerability analysis unit 27 adds the association between the plurality of information assets obtained from the information asset-variable correspondence 47 (FIG. 10) and the plurality of variables to the program specification 42. Can perform vulnerability analysis. In addition, the vulnerability analysis unit 27 can perform the vulnerability analysis by referring to the threat type 444 (C, I, A) described in the threat analysis result 44. That is, the vulnerability analysis unit 27 can perform the vulnerability analysis by adding the threat type 444 (C, I, A) to the program specification 42.
Further, in the present embodiment, the vulnerability analysis unit 27 extracts a portion in which the processing related to the candidate of the vulnerability type extracted by the vulnerability candidate extraction unit 26 is described as a program fragment from the program specification 42. be able to. Then, the vulnerability analysis unit 27 can perform a vulnerability analysis using the extracted program fragment. In this case, the vulnerability analysis unit 27, from the program specification 42, for example, a process of referencing or changing a variable related to the threat, a process using another variable that affects the variable related to the threat, and a branch process. , The process that controls the execution of the above-mentioned processes such as the determination process can be extracted as a program fragment.
The matters not described in the present embodiment are the same as those in the first embodiment.

As described above, in the present embodiment, vulnerability inspection is performed by adding meta information such as the correspondence between information assets and variables and the value of information assets (C, I, A) to the program specifications to be inspected. Do. Therefore, in the present embodiment, it is possible to improve the efficiency of the generation of the inspection formula and / and the generation of the model.
Further, in the present embodiment, by using the program fragment, the vulnerability analysis can be made more efficient as compared with the case where the entire program specification is used.

Although the embodiments of the present invention have been described above, two or more of these embodiments may be combined and implemented.
Alternatively, one of these embodiments may be partially implemented.
Alternatively, two or more of these embodiments may be partially combined and implemented.
The present invention is not limited to these embodiments, and various modifications can be made as needed.

*** Explanation of hardware configuration ***
Finally, a supplementary explanation of the hardware configuration of the vulnerability analyzer 10 will be given.

The OS (Operating System) is stored in the storage 13.
Then, at least a part of the OS is loaded into the memory 12 and executed by the processor 11.
While executing at least a part of the OS, the processor 11 has a first reception unit 21, a variable determination unit 22, a candidate generation unit 23, a second reception unit 24, a related threat extraction unit 25, and a vulnerability candidate extraction unit 26. Execute the program that realizes the functions of the vulnerability analysis unit 27 and the information asset determination unit 28.
When the processor 11 executes the OS, task management, memory management, file management, communication control, and the like are performed.
Further, the first reception unit 21, the variable discrimination unit 22, the candidate generation unit 23, the second reception unit 24, the related threat extraction unit 25, the vulnerability candidate extraction unit 26, the vulnerability analysis unit 27, and the information asset discrimination unit 28. At least one of the information, data, signal value, and variable value indicating the result of the processing is stored in at least one of the memory 12, the storage 13, and the register and the cache memory in the processor 11.
Further, the first reception unit 21, the variable discrimination unit 22, the candidate generation unit 23, the second reception unit 24, the related threat extraction unit 25, the vulnerability candidate extraction unit 26, the vulnerability analysis unit 27, and the information asset discrimination unit 28. The program that realizes the above functions may be stored in a portable recording medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a Blu-ray (registered trademark) disk, or a DVD. Then, the first reception unit 21, the variable discrimination unit 22, the candidate generation unit 23, the second reception unit 24, the related threat extraction unit 25, the vulnerability candidate extraction unit 26, the vulnerability analysis unit 27, and the information asset discrimination unit 28. A portable recording medium containing a program that realizes the above functions may be commercially distributed.

In addition, the first reception unit 21, the variable discrimination unit 22, the candidate generation unit 23, the second reception unit 24, the related threat extraction unit 25, the vulnerability candidate extraction unit 26, the vulnerability analysis unit 27, and the information asset discrimination unit 28. "Part" may be read as "circuit" or "process" or "procedure" or "process".
Further, the vulnerability analyzer 10 may be realized by a processing circuit. The processing circuit is, for example, a logic IC (Integrated Circuit), a GA (Gate Array), an ASIC (Application Specific Integrated Circuit), or an FPGA (Field-Programmable Gate Array).
In this specification, the superordinate concept of the processor and the processing circuit is referred to as "processing circuit Lee".
That is, the processor and the processing circuit are specific examples of the "processing circuit Lee", respectively.

10 Vulnerability analyzer, 11 Processor, 12 Memory, 13 Storage, 14 Communication interface, 21 1st reception unit, 22 Variable discrimination unit, 23 Candidate generation unit, 24 2nd reception unit, 25 Related threat extraction unit, 26 Vulnerability Candidate Extraction Department, 27 Vulnerability Analysis Department, 28 Information Asset Discrimination Department, 31 Processing Type DB, 32 Threat-Vulnerability Type Response DB, 41 Information Asset Flow, 42 Program Specifications, 43 Correspondence between Components and Program Specifications , 44 Threat analysis result, 45 Program variable processing relationship, 46 Information asset-variable correspondence relationship candidate, 47 Information asset-variable correspondence relationship, 48 Related threat list, 49 Vulnerability type candidate, 410 Vulnerability detection result.

Claims (15)

A variable discriminator that discriminates each type of multiple variables included in the program executed by the device,
Each type of the plurality of variables determined by the variable discriminating unit is compared with each type of the plurality of information assets used by the device, and each of the plurality of information assets and each of the plurality of variables An information processing device having a candidate generation unit that generates one or more candidates for a correspondence relationship. The information processing device further
The information processing apparatus according to claim 1, further comprising an output unit that outputs the plurality of correspondence relationship candidates when a plurality of correspondence relationship candidates are generated by the candidate generation unit. The variable discriminating unit is
It is determined whether each of the plurality of variables is an input variable, an output variable, or an internally used variable.
The candidate generation unit
Input information assets and input variables which are information assets input from the outside of the device to the device, output information assets and output variables which are information assets output from the device to the outside of the device, and the inside of the device. The information processing device according to claim 1, wherein the internal use information asset, which is the information asset used in the above, is associated with the internal use variable to generate one or more correspondence candidates. The candidate generation unit
Each of the plurality of information assets acquires information asset information indicating which of the input information asset, the output information asset, and the internal use information asset, and the input information asset shown in the information asset information The information processing apparatus according to claim 3, wherein the input variable, the output information asset and the output variable shown in the information asset information, and the internal use information asset and the internal use variable shown in the information asset information are associated with each other. .. The information processing device further
The information processing apparatus according to claim 3, further comprising an information asset discriminating unit that discriminates whether each of the plurality of information assets is the input information asset, the output information asset, or the internal use information asset. The variable discriminating unit is
It is determined whether the process in which each of the plurality of variables is used is an input process, an output process, or an internal use process, and each type of the plurality of variables is determined based on the type of the determined process. The information processing apparatus according to claim 3. The variable discriminating unit is
Analyzing the propagation relationship of variable values in the plurality of variables,
The output unit
The information processing apparatus according to claim 2, which outputs one or more correspondence relationship candidates generated by the candidate generation unit and a propagation relationship of variable values obtained by analysis of the variable discrimination unit. The candidate generation unit
When a plurality of correspondence candidates are generated, a priority is set among the plurality of correspondence candidates.
The output unit
The information processing apparatus according to claim 2, wherein the candidate for the correspondence relationship having a high priority is preferentially output. The candidate generation unit
The information processing according to claim 8, wherein the certainty of each of the plurality of correspondence candidates is estimated as a correspondence candidate, and a priority is set among the plurality of correspondence candidates based on the estimation result. apparatus. The information processing device further
A vulnerability candidate extraction unit that extracts candidates for the types of vulnerabilities existing in the device based on a correspondence relationship selected from the one or more correspondence relationship candidates.
The information processing apparatus according to claim 1, further comprising a vulnerability analysis unit that analyzes the vulnerability of the device based on the candidate for the type of vulnerability extracted by the vulnerability candidate extraction unit. The vulnerability candidate extraction unit
The information processing apparatus according to claim 10, wherein a candidate for a type of vulnerability existing in the device is extracted with reference to an attack tree. Candidates for the type of vulnerability The vulnerability analysis department
The information processing apparatus according to claim 10, wherein the vulnerability analysis of the device is performed with reference to at least one of the association between the plurality of information assets and the plurality of variables and the type of threat. The vulnerability analysis department
The part in which the process related to the candidate of the vulnerability type extracted by the vulnerability candidate extraction unit is described is extracted as a program fragment from the program, and the extracted program fragment is used to analyze the vulnerability of the device. The information processing apparatus according to claim 10. The computer determines the type of each of the multiple variables contained in the program running on the device.
The computer compares each type of the determined plurality of variables with each type of the plurality of information assets used by the device, and each of the plurality of information assets and each of the plurality of variables An information processing method that generates one or more correspondence candidates. Variable discrimination processing that discriminates each type of multiple variables included in the program executed by the device, and
Each type of the plurality of variables determined by the variable discrimination process is compared with each type of the plurality of information assets used by the device, and each of the plurality of information assets and each of the plurality of variables An information processing program that causes a computer to execute a candidate generation process that generates one or more candidates for the correspondence.

Images