WO2020261430A1 - 情報処理装置、情報処理方法及び情報処理プログラム - Google Patents
情報処理装置、情報処理方法及び情報処理プログラム Download PDFInfo
- Publication number
- WO2020261430A1 WO2020261430A1 PCT/JP2019/025382 JP2019025382W WO2020261430A1 WO 2020261430 A1 WO2020261430 A1 WO 2020261430A1 JP 2019025382 W JP2019025382 W JP 2019025382W WO 2020261430 A1 WO2020261430 A1 WO 2020261430A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- threat
- program
- information
- function
- vulnerability
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
Definitions
- the present invention relates to a technique for determining whether or not countermeasures against security threats are taken in the program.
- System or device security measures are generally implemented according to the following procedure. First, in the upstream process of development, threats that may occur in the system or equipment are extracted. Next, a process called risk analysis is performed to assess the magnitude of damage caused by the extracted threats. Then, as a result of risk analysis, the priority of threats to be dealt with is grasped, the policy of security measures for each threat is established, and the security measures are concreted at each stage of the development process. For example, when data is encrypted as a countermeasure against data eavesdropping, the encryption and decryption logic is reflected in the software design. In addition, the hardware configuration for securely storing the encryption key is reflected in the system design. On the other hand, when screen lock is used as a countermeasure against unauthorized access to a PC (Personal Computer), the thoroughness of screen lock is reflected in the system operation manual.
- PC Personal Computer
- static analysis There is static analysis as a security measure performed at the implementation stage of software development.
- vulnerabilities that are software problems that lead to security threats are mainly source code without operating software execution code. Is identified by analyzing.
- static analysis there is a method called taint analysis that tracks the data flow.
- the input data from the outside is regarded as contaminated data (taint). Then, in the taint analysis, the data flow from the input of the data to the use of the data is tracked.
- the taint analysis it is determined whether or not there is a data verification process and / and a data detoxification process before using the data. If there is no data validation process and / and data detoxification process, the contaminated data will be used as it is. If there is no data validation processing and / and data detoxification processing, it is determined that there is a vulnerability because illegal processing may be executed. On the other hand, if there is data validation processing and / and data detoxification processing, it can be considered that the contaminated data has been removed, and therefore it is determined that there is no vulnerability.
- Patent Document 1 describes a method of detecting a vulnerable route in a source code. Specifically, in the source code, a data flow that defines a procedure in which data is input from the outside and data is output to the outside is extracted. Then, the vulnerability route is detected by collating the extracted data flow with the points of occurrence and points of use of the vulnerabilities registered in the database.
- Patent Document 1 In the technology of Patent Document 1, only the program is analyzed and the threat is extracted only from the program. Therefore, in Patent Document 1, there is a possibility that threat extraction omission occurs and sufficient measures cannot be taken.
- the main object of the present invention is to solve such a problem. More specifically, it is a main object of the present invention to be able to take countermeasures against threats that cannot be extracted only by analyzing the program.
- the information processing device is The threats that can occur during the execution of the program identified by risk analysis based on the program specifications that show the program specifications, and the threat involvement that is the element that is involved in the occurrence of the threat among the elements shown in the program specifications.
- the threat information acquisition unit that acquires the threat information that indicates the element, Among the variables described in the program, the variables corresponding to the threat-related elements are extracted as threat-related variables, the program is analyzed based on the extracted threat-related variables, and countermeasures against the threat are taken in the program. It has a determination unit for determining whether or not it is.
- FIG. 1 shows the hardware configuration example of the security design apparatus which concerns on Embodiment 1.
- FIG. which shows the example of the threat information which concerns on Embodiment 1.
- FIG. 1 shows a hardware configuration example of the security design device 100 according to the first embodiment.
- the security design device 100 corresponds to an information processing device. Further, the operation procedure of the security design device 100 corresponds to an information processing method.
- the security design device 100 is a computer.
- the security design device 100 includes a processor 101, a main storage device 102, an auxiliary storage device 103, an input interface 111, a display interface 112, and a network interface 113. These hardware elements are connected by a data bus 114.
- FIG. 1 shows an example of arranging each data at the time of executing the verification program 104 that realizes the function of the security design device 100.
- the verification program 104, the program 105, the software trace information 106, the countermeasure function information 107, the threat information 108, and the vulnerability information 109 are arranged in the main storage device 102.
- the vulnerability DB 110 is arranged in the auxiliary storage device 103.
- the verification program 104 corresponds to an information processing program.
- the verification program 104 is usually stored in the auxiliary storage device 103, and at the time of execution, the verification program 104 is read into the main storage device 102 by the processor 101 and executed by the processor 101.
- the verification program 104 is a program that realizes the functions of the threat information acquisition unit 201, the vulnerability identification information selection unit 202, the threat involvement variable extraction unit 203, the vulnerability determination unit 204, and the vulnerability information generation unit 205.
- FIG. 1 schematically shows a state in which the processor 101 is executing the verification program 104. That is, in FIG. 1, the processor 101 executes the verification program 104 to execute the threat information acquisition unit 201, the vulnerability identification information selection unit 202, the threat involvement variable extraction unit 203, the vulnerability determination unit 204, and the vulnerability information generation unit.
- the state of operating as 205 is schematically shown.
- the verification program 104, software trace information 106, countermeasure function information 107, and threat information 108 include threat information acquisition unit 201, vulnerability identification information selection unit 202, threat involvement variable extraction unit 203, vulnerability determination unit 204, and vulnerability information generation. Used by any of parts 205. Any one of the program 105, the software trace information 106, the countermeasure function information 107, and the threat information 108 is input from the input interface 111 or the network interface 113 and transferred to the main storage device 102. Further, any one of the program 105, the software trace information 106, the countermeasure function information 107, and the threat information 108 is transferred to the main storage device 102 by reading from the auxiliary storage device 103.
- Vulnerability information 109 is output from the vulnerability information generation unit 205. Vulnerability information 109 is stored in, for example, the auxiliary storage device 103. Further, the vulnerability information 109 may be displayed on the display device through the display interface 112. Further, the vulnerability information 109 may be transferred to the outside through the network interface 113.
- FIG. 2 shows an example of a functional configuration and an example of a data flow of the security design device 100 according to the first embodiment.
- the security design device 100 verifies the presence or absence of countermeasures in the program 105 by using the software trace information 106, the threat information 108, and the vulnerability DB 110. Further, the security design device 100 has a threat information acquisition unit 201, a vulnerability identification information selection unit 202, a threat involvement variable extraction unit 203, a vulnerability determination unit 204, and a vulnerability information generation unit 205 as functional configurations.
- the vulnerability identification information selection unit 202, the threat involvement variable extraction unit 203, and the vulnerability determination unit 204 correspond to the determination unit 250. Further, the processing performed by the vulnerability identification information selection unit 202, the threat involvement variable extraction unit 203, and the vulnerability determination unit 204 corresponds to the determination processing.
- the program 105 is a program to be verified by the security design device 100. That is, the security design device 100 determines whether or not countermeasures against threats that may occur when the program 105 is executed are taken in the program 105.
- the program 105 is applied to the communication software (hereinafter referred to as communication S / W) of the device controller of the control system.
- Program 105 is a specification that defines the operation of the device controller in detail. For example, the source code written in the programming language corresponds to the program 105.
- FIG. 4 shows an example of the communication S / W 303 of the device controller of the control system, that is, the program 105.
- the program 105 is generated at the implementation stage of software development. In normal software development, for example, there is a system design stage prior to implementation. Then, at the stage of system design, the system configuration and the general operation of the system are defined.
- FIG. 3 shows an example of the system configuration diagram 300 and the program specification diagram 310 of the control system.
- the system configuration diagram 300 and the program specification diagram 310 are examples of program specifications.
- a program specification is information that indicates a program specification.
- the program specification is a software development product generated prior to coding the program 105.
- the control system is composed of an HMI (Human Machine Interface) 301, an equipment controller 302, and a field equipment 304.
- the HMI 301 and the device controller 302 are connected by a transmission line 305, and the device controller 302 and the field device 304 are connected by a transmission line 306.
- the HMI 301 is a terminal for the operator to monitor and control the control system. According to the operation by the operator in the HMI 301, the control command 308 of any one of START, STOP and READ is transmitted from the HMI 301 to the equipment controller 302 via the transmission line 305. Further, the HMI 301 receives the sensor information as a response from the device controller 302.
- the device controller 302 controls the field device 304 according to the instruction from the HMI 301.
- the transmission / reception function of the device controller 302 is realized by the communication S / W 303. More specifically, the communication S / W 303 receives the control command 308 transmitted from the HMI 301 via the transmission line 305. Further, the communication S / W 303 transmits an ON or OFF control signal 309 to the field device 304 according to the control command 308 received from the HMI 301. Further, the communication S / W 303 receives the sensor information transmitted from the field device 304. Further, the communication S / W 303 transmits sensor information to the HMI 301 as a response to the control command 308.
- the communication S / W 303 will be specified and refined according to the stage of software development. For example, a system configuration diagram 300 is generated to define an outline of the operation of the communication S / W 303, and then a program specification diagram 310 is generated to define the program specifications of the communication S / W 303. Then, the program 105, which is the source code, is generated, which is further refined at the implementation stage.
- Program specification diagram 310 is a state transition diagram.
- the program specification diagram 310 is composed of a state transition 311 and a state 312, a state 313, a state transition 314, and a state transition 315.
- the state 312 is a state having a label of SYSTEM_OFF.
- State 313 is a state having a label of SYSTEM_ON.
- the state transition 311 is a state transition from the state 312 to the state 313.
- the state transition 314 is a state transition from the state 313 to the state 312.
- the state transition 315 is a state transition from the state 313 to the state 313.
- the state transition 311 when the state is SYSTEM_OFF, if the condition "receive the control command START from the HMI” is satisfied, the process "send the control signal ON to the field device” is executed, and the state transitions to SYSTEM_ON. Means. This defines the operation of the communication S / W 303 of the device controller 302, which transmits a control signal ON to the field device 304 when the control command START is received from the HMI 301.
- the state transition 314 when the state is SYSTEM_ON, if the condition "receive the control command STOP from the HMI” is satisfied, the process "send the control signal OFF to the field device” is executed, and the state transitions to SYSTEM_OFF. Means.
- the state transition 315 has two processes, "read sensor information from field device” and “send sensor information to HMI", if the condition "receive control command READ from HMI” is satisfied when the state is SYSTEM_ON. Is executed, and the state transitions to SYSTEM_ON, that is, the state remains SYSTEM_ON and does not change.
- specifications such as the system configuration diagram 300, the program specification diagram 310, and the program 105 are generated according to each stage of the development process, and they correspond to each other. Can be attached.
- traceability the property that each artifact is associated with each other and can be traced. This ensures that, for example, the requirements are correctly reflected in the design and implementation.
- the software trace information 106 is information in which the elements of the program 105 and the elements of the program specifications that are related to each other are associated with each other.
- FIG. 5 shows an example of software trace information 106 according to the present embodiment.
- the software trace information 106 is composed of items of system design, program design, and implementation.
- the software trace information 106 is information that associates deliverables generated at each stage of software development with each other. For example, from the number 1 line, it can be seen that the deliverables of each stage are the system configuration diagram 300, the program specification diagram 310, and the program 105. Further, from the line No. 2, it can be seen that the control command in the system configuration diagram 300 corresponds to the control command in the program specification diagram 310, and also corresponds to the variable cmd in the program 105.
- the threat information 108 is, for example, the information shown in FIG.
- the threat information 108 is information that defines a security threat to a device on which the software to be developed is installed and a system in which the device is used.
- the threat information 108 of FIG. 6 shows a list of security threats extracted by the risk analysis based on the system configuration diagram 300 of FIG.
- the threat information 108 is composed of threats, information assets, and vulnerabilities.
- a "threat" is a threat that can occur when program 105 is executed.
- the threat is a threat identified by risk analysis based on the program specification (system configuration diagram 300 in this example).
- the user may identify the threat by performing a risk analysis with reference to the program specifications, or may have a specific analysis tool perform a risk analysis based on the program specifications to identify the threat.
- “Information assets” are the elements shown in the program specifications that are involved in the occurrence of threats.
- the information assets shown in the threat information 108 are also referred to as threat-related elements.
- a "vulnerability” is a vulnerability that causes a threat and is a vulnerability that exists in Program 105.
- the vulnerability is represented by a vulnerability identifier called CWE (Common Weekness Enumeration). From the example of FIG. 7, there is a threat of "stopping the field device due to falsification of the control command between the HMI and the device controller", and the information asset involved in the occurrence of the threat is the "control command”. It can be seen that the vulnerability that causes the threat is "CWE-20". Vulnerabilities can also be expressed in formats other than CWE.
- Vulnerability countermeasure processing information 115 is composed of items of vulnerability and countermeasure processing.
- the "vulnerability” is the vulnerability shown in the threat information 108.
- Countermeasure processing is a processing that realizes countermeasures against threats. Specifically, the "countermeasure process” indicates a process for eliminating the threat.
- the countermeasure function information 107 is, for example, the information shown in FIG.
- the countermeasure function information 107 includes countermeasure processing, a library, and countermeasure function items.
- the “countermeasure process” is the countermeasure process shown in the vulnerability countermeasure process information 115.
- “Library” refers to the library used by program 105.
- the “countermeasure function” indicates a function that realizes the countermeasure processing in the library used by the program 105. Specifically, it is a function for eliminating threats.
- the threat information acquisition unit 201 acquires the threat information 108. Then, the threat information acquisition unit 201 generates the vulnerability identifier 211 and the threat involvement element information 212 from the threat information 108. Further, the threat information acquisition unit 201 outputs the vulnerability identifier 211 to the vulnerability identification information selection unit 202, and outputs the threat involvement element information 212 to the threat involvement variable extraction unit 203. Specifically, the threat information acquisition unit 201 extracts the vulnerability (for example, “CWE-20”) shown in the threat information 108. Further, the threat information acquisition unit 201 generates a vulnerability identifier 211 for notifying the extracted vulnerability, and outputs the vulnerability identifier 211 to the vulnerability identification information selection unit 202.
- the vulnerability for example, “CWE-20”
- the threat information acquisition unit 201 generates threat-related element information 212 that notifies the information asset (for example, “control command”) shown in the threat information 108. Then, the threat information acquisition unit 201 outputs the threat involvement element information 212 to the threat involvement variable extraction unit 203. The process performed by the threat information acquisition unit 201 corresponds to the threat information acquisition process.
- the vulnerability identification information selection unit 202 acquires the vulnerability identifier 211 from the threat information acquisition unit 201. Further, the vulnerability identification information selection unit 202 acquires the program 105 and the countermeasure function information 107. Then, the vulnerability identification information selection unit 202 searches for the vulnerability countermeasure processing information 115 in the vulnerability DB 110 based on the vulnerability identifier 211. As a result, the vulnerability identification information selection unit 202 identifies the countermeasure processing for the vulnerability notified by the vulnerability identifier 211. In addition, the vulnerability identification information selection unit 202 analyzes the program 105 and identifies the library used in the program 105. Then, the vulnerability identification information selection unit 202 extracts the countermeasure function corresponding to the specified countermeasure process and the library from the countermeasure function information 107. Then, the vulnerability specific information selection unit 202 generates the function specific information 213 that notifies the countermeasure function extracted from the countermeasure function information 107, and outputs the generated function specific information 213 to the vulnerability determination unit 204.
- the threat involvement variable extraction unit 203 acquires software trace information 106 and threat involvement element information 212. Then, the threat involvement variable extraction unit 203 extracts the information asset (threat involvement element) shown in the threat involvement element information 212 and the element of the program 105 associated with the software trace information 106. More specifically, the threat involvement variable extraction unit 203 extracts the information asset (threat involvement element) shown in the threat involvement element information 212 and the variable of the program 105 associated with the software trace information 106. The variables extracted by the threat involvement variable extraction unit 203 are referred to as threat involvement variables. The threat involvement variable extraction unit 203 generates threat involvement variable information 214 for notifying the extracted threat involvement variables. Then, the threat involvement variable extraction unit 203 outputs the generated threat involvement variable information 214 to the vulnerability determination unit 204.
- the vulnerability determination unit 204 acquires the program 105, the function specific information 213, and the threat involvement variable information 214. Then, the vulnerability determination unit 204 determines whether or not the countermeasure function shown in the threat involvement variable information 214 is described in an appropriate place in the program 105. When the countermeasure function is described in an appropriate place in the program 105, the vulnerability determination unit 204 determines that the countermeasure against the threat is taken in the program 105. On the other hand, if the countermeasure function is not described in an appropriate place in the program 105, the vulnerability determination unit 204 determines that the countermeasure against the threat is not taken in the program 105.
- the vulnerability determination unit 204 extracts the input processing function associated with the threat involvement variable and the output processing function associated with the threat involvement variable shown in the threat involvement variable information 214. Then, the vulnerability determination unit 204 determines whether or not a countermeasure function is described between the extracted input processing function and the output processing function. When the countermeasure function is described between the input processing function and the output processing function, the vulnerability determination unit 204 determines that the countermeasure against the threat is taken in the program 105. On the other hand, if the countermeasure function is not described between the input processing function and the output processing function, the vulnerability determination unit 204 determines that no countermeasure against the threat has been taken in the program 105. Then, the vulnerability determination unit 204 outputs the determination result 215 to the vulnerability information generation unit 205.
- Vulnerability information generation unit 205 acquires the determination result 215. Then, the vulnerability information generation unit 205 generates the vulnerability information 109 from the determination result 215 and outputs the vulnerability information 109. As described above, the vulnerability information generation unit 205 outputs, for example, the vulnerability information 109 to the auxiliary storage device 103. Further, the vulnerability information generation unit 205 may output the vulnerability information 109 to the outside via the network interface 113, or may output the vulnerability information 109 to the display device via the display interface 112.
- FIG. 10 is a flowchart showing an operation example of the security design device 100 according to the first embodiment.
- step S701 the threat information acquisition unit 201 acquires the threat information 108.
- step S702 the threat information acquisition unit 201 generates the vulnerability identifier 211 and the threat involvement element information 212 from the threat information 108.
- step S703 the vulnerability identification information selection unit 202 extracts the countermeasure function from the countermeasure function information 107 with reference to the program 105 and the vulnerability countermeasure processing information 115.
- step S704 the threat involvement variable extraction unit 203 extracts the threat involvement variable by referring to the threat involvement element information 212 and the software trace information 106.
- step S705 the vulnerability determination unit 204 extracts the input processing function and the output processing function from the program 105 with reference to the threat involvement variable information 214.
- step S706 the vulnerability determination unit 204 extracts the input processing function and the output processing function, and measures are taken in the program 105 based on the extracted input processing function and the output processing function and the countermeasure function shown in the function specific information 213. Determine if processing has been taken.
- step S707 the vulnerability information generation unit 205 formats the determination result 215 of the vulnerability determination unit 204 and outputs the vulnerability information 109.
- Step S701 The threat information acquisition unit 201 acquires the threat information 108 shown in FIG.
- Step S702 The threat information acquisition unit 201 extracts the value of the information asset and the value of the vulnerability corresponding to each threat from the threat information 108.
- the threat information acquisition unit 201 extracts the value of the information asset and the value of the vulnerability line by line.
- the threat information acquisition unit 201 outputs the threat involvement element information 212 indicating the value of the extracted information asset to the threat involvement variable extraction unit 203.
- the threat information acquisition unit 201 outputs the vulnerability identifier 211 indicating the extracted vulnerability value to the vulnerability identification information selection unit 202.
- the threat information acquisition unit 201 extracts the “control command” from the information asset column, and outputs the threat involvement element information 212 indicating the “control command” as the threat involvement element to the threat involvement variable extraction unit 203. To do. Further, the vulnerability identification information selection unit 202 extracts "CWE-20" from the vulnerability column and outputs the vulnerability identifier 211 indicating "CWE-20" to the vulnerability identification information selection unit 202. The threat information acquisition unit 201 also outputs the vulnerability identifier 211 and the threat-related element information 212 for the lines after the number 2.
- the vulnerability identification information selection unit 202 acquires the vulnerability identifier 211 from the threat information acquisition unit 201. Further, the vulnerability identification information selection unit 202 acquires the program 105 and the countermeasure function information 107. Then, the vulnerability identification information selection unit 202 searches for the vulnerability countermeasure processing information 115 in the vulnerability DB 110 based on the vulnerability identifier 211, and identifies the countermeasure processing. For example, when the vulnerability identifier 211 indicating "CWE-20" is acquired, the vulnerability identification information selection unit 202 searches for the vulnerability countermeasure processing information 115 illustrated in FIG. 7 using "CWE-20" as a key. Then, "input verification" is extracted as a countermeasure process corresponding to "CWE-20".
- the vulnerability identification information selection unit 202 analyzes the program 105 and identifies the library used in the program 105.
- the vulnerability identification information selection unit 202 specifies "SSL" as the library used in the program 105.
- the vulnerability identification information selection unit 202 refers to the countermeasure function information 107 and extracts the countermeasure function corresponding to “input verification” and “SSL”.
- the vulnerability identification information selection unit 202 extracts “verifyInput” as a countermeasure function.
- the vulnerability identification information selection unit 202 outputs the function identification information 213 indicating the countermeasure function “verifyInput” to the vulnerability determination unit 204.
- the threat involvement variable extraction unit 203 acquires the threat involvement element information 212 from the threat information acquisition unit 201. Further, the threat involvement variable extraction unit 203 acquires the software trace information 106. Then, the threat-related variable extraction unit 203 extracts variables (threat-related variables) corresponding to the information assets (threat-related elements) shown in the threat-related element information 212. Here, it is assumed that the threat involvement variable extraction unit 203 has acquired the threat involvement element information 212 in which the information asset “control command” is indicated. The threat involvement variable extraction unit 203 extracts the “variable cmd”, which is the value in the “implementation” column corresponding to the “control command”, as the threat involvement variable with reference to the software trace information 106 of FIG. The threat involvement variable extraction unit 203 outputs the threat involvement variable information 214 indicating the extracted threat involvement variable “variable cmd” to the vulnerability determination unit 204.
- Vulnerability determination unit 204 acquires threat involvement variable information 214 from threat involvement variable extraction unit 203.
- the vulnerability information generation unit 205 acquires the program 105.
- the vulnerability determination unit 204 extracts the input processing function and the output processing function associated with the threat involvement variable shown in the threat involvement variable information 214. It is assumed that the vulnerability determination unit 204 has acquired the threat involvement variable information 214 indicating the “variable cmd”. In this case, the vulnerability determination unit 204 extracts the input processing function and the output processing function associated with the “variable cmd” in the program 105 of FIG. Specifically, from the program 105 of FIG.
- the vulnerability determination unit 204 is associated with the function “receiveFromHMI” indicated by the reference numeral 402 and the function “sendToDevice” (reference numeral 403 “cmd”) indicated by the reference numeral 404. Is).
- the range from reference numeral 402 to reference numeral 404 represents the data flow from the input of the variable cmd to the use of the variable cmd.
- the vulnerability determination unit 204 acquires the function identification information 213 from the vulnerability identification information selection unit 202.
- the vulnerability determination unit 204 determines whether or not the countermeasure function shown in the function specific information 213 is described between the input processing function and the output processing function extracted in step S705. It is assumed that the vulnerability determination unit 204 extracts the function "receiveFromHMI" as an input processing function and extracts the function "sendToDevice” as an output processing function in step S705. Further, it is assumed that the vulnerability determination unit 204 has acquired the function specific information 213 indicating "verifyInput" as a countermeasure function.
- the vulnerability determination unit 204 determines whether or not the countermeasure function "verifyInput” is described between the function “receiveFromHMI” (reference numeral 402) and the function “sendToDevice” (reference numeral 404) of the program 105.
- the countermeasure function "verifyInput” is not described between the function “receiveFromHMI” (reference numeral 402) and the function “sendToDevice” (reference numeral 404). Therefore, the vulnerability determination unit 204 determines that the program 105 does not take measures against the threat shown in the threat information 108. That is, the vulnerability determination unit 204 determines that the program 105 has a vulnerability.
- a countermeasure function "verifyInput” (reference numeral 405) is described between the function “receiveFromHMI” (reference numeral 402) and the function “sendToDevice” (reference numeral 404). Therefore, the vulnerability determination unit 204 determines that the program 105 has taken measures against the threat shown in the threat information 108. That is, the vulnerability determination unit 204 determines that the program 901 is not vulnerable. The vulnerability determination unit 204 outputs the determination result 215 to the vulnerability information generation unit 205. When the vulnerability determination unit 204 determines that no countermeasures against threats have been taken in the program 105, for example, the name of the program 105, the threat, the information assets that are the threat-related elements, the vulnerability identifier, and the like.
- the judgment result 215 showing the threat-related variables, the vulnerable function, and the place where the vulnerable function is described is output.
- the vulnerability determination unit 204 shows, for example, the name of the program 105, the threat, and a message indicating that the countermeasure has been taken. Outputs 215. If it is determined in the program 105 that countermeasures against threats have been taken, the vulnerability determination unit 204 does not have to output the determination result 215.
- Step S707 The vulnerability information generation unit 205 acquires the determination result 215 from the vulnerability determination unit 204. Then, the vulnerability information generation unit 205 shapes the determination result 215 and outputs the determined determination result 215 after the shaping as the vulnerability information 109.
- FIG. 11 shows an example of vulnerability information 109. In FIG. 11, the values of “threat”, “information asset”, and “vulnerability” are the same as the values of threat information 108.
- the name of the program 105 is described in the item of "program”. In the "start line: end line”, the line of the program 105 in which the function shown in the "function” item is described is described. Threat-related variables are described in “Variables”. "Function" describes a vulnerable function.
- the security design device 100 performs the processing after step S702 in FIG. 7 for each line of the threat information 108. Further, when a plurality of programs 105 are targeted for verification, the security design device 100 performs the processes after step S701 in FIG. 7 for each program 105. Even if there are a plurality of countermeasure functions and a plurality of threat-related variables, the security design device 100 repeatedly performs the corresponding processing as appropriate.
- the software trace information 106 used in this embodiment is generated as a part of software development, it is not necessary to generate new data for vulnerability analysis. Therefore, more rigorous vulnerability analysis can be realized without increasing the time and effort of the user who performs the vulnerability analysis.
- information on variables and functions required for vulnerability analysis can be obtained from the program at the implementation stage. Therefore, according to the present embodiment, it is possible to identify specific vulnerabilities such as confidentiality and integrity.
- Conventional technology has not been able to identify vulnerabilities related to confidentiality, integrity, and availability, which are called the three elements of security. For example, in order to identify vulnerabilities related to data integrity, it is first determined that the target data is data that cannot be tampered with, and then whether or not measures are taken to prevent tampering. Need to be evaluated. However, since the program (source code) does not have information on data integrity, it is not possible to identify the integrity vulnerability. In the present embodiment, as shown in FIG.
- the security design device 100 sets the threat related to integrity in the program 105. It is possible to evaluate whether or not measures have been taken against. Further, if a confidentiality threat (for example, leakage) is described in the threat information 108 by the risk analysis based on the program specification, the security design device 100 takes measures against the confidentiality threat in the program 105. It is possible to evaluate whether or not it is. Further, when a threat related to availability (for example, a DoS (Denial of Service) attack) is described in the threat information 108 by risk analysis, the security design device 100 takes measures against the threat related to availability in the program 105. Whether or not it can be evaluated.
- a confidentiality threat for example, leakage
- the security design device 100 takes measures against the confidentiality threat in the program 105. It is possible to evaluate whether or not it is.
- a threat related to availability for example, a DoS (Denial of Service) attack
- the security design device 100 takes measures against the threat related to availability in the program 105. Whether or not it can be evaluated.
- Embodiment 2 The above-described first embodiment does not depend on a specific vulnerability location identification method, but in the second embodiment, an example of using taint analysis, which is a kind of static analysis, as a vulnerability location identification method will be described. To do. Further, in the second embodiment, an example of using the type inspection as a method of realizing the taint analysis 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.
- FIG. 12 shows an example of the functional configuration of the security design device 100 according to the second embodiment.
- the type notification unit 206 is added.
- the function specific information 213 and the threat involvement variable information 214 are input to the type notification unit 206, and the type information program 216 is output from the type notification unit 206 to the vulnerability determination unit 204.
- the type notification unit 206 is also realized by the verification program 104 in the same manner as the threat information acquisition unit 201 and the like.
- two programs 105 are described, but this is due to drawing reasons, and both are the same. That is, the program 105 input to the type notification unit 206 and the program 105 input to the vulnerability identification information selection unit 202 are the same.
- FIG. An example of the hardware configuration of the security design device 100 is as shown in FIG. Although not shown, in the present embodiment, the block of the type notification unit 206 is added to the block of the processor 101. Further, in the present embodiment, the block of the type information program 216 is added to the block of the main storage device 102.
- the type notification unit 206 notifies the vulnerability determination unit 204 of the return type of the input processing function, the argument type of the output processing function, the argument type of the countermeasure function, and the return value type.
- the type notification unit 206 includes in the type information program 216 the type of the return value of the input processing function, the type of the argument of the output processing function, and the type information indicating the argument of the countermeasure function and the type of the return value. That is, the type information program 216 is the program 105 to which the type information is added.
- the vulnerability determination unit 204 sets the return type of the input processing function, the argument type of the output processing function, the argument type of the countermeasure function, and the return value type notified by the type information of the type information program 216. Based on, it is determined whether or not the countermeasure function is described between the input processing function and the output processing function.
- FIG. 13 shows an example of type information 217 added to the program 105 by the type notification unit 206.
- the program 105 to which the type information 217 is added corresponds to the type information program 216. Details of FIG. 13 will be described later.
- the countermeasure function information 107 includes information on the type of the argument and the return value of the countermeasure function. Specifically, "int ⁇ intsure>" is described as the argument type of the countermeasure function "verifyInput”, and "int ⁇ secure>” is described as the return type.
- FIG. 15 shows an operation example of the security design device 100 according to the present embodiment.
- the program 105 shown in FIG. 4 is the verification target. Further, as in the first embodiment, it is assumed that "cmd" is described as the threat involvement variable in the threat involvement variable information 214.
- steps S701 and S702 are the same as those shown in the first embodiment, the description thereof will be omitted.
- step S801 the vulnerability identification information selection unit 202 extracts the countermeasure function and outputs the function identification information 213 in the same procedure as in step S703 of the first embodiment. However, in step S801, the vulnerability identification information selection unit 202 outputs the function identification information 213 to the type notification unit 206. Further, in the function specific information 213, "argument type: int ⁇ intsure>” and “return value type: int ⁇ seture>" shown in FIG. 14 are described.
- step S704 is the same as that shown in the first embodiment, the description thereof will be omitted.
- step S802 the type notification unit 206 analyzes the program 105 and extracts the input processing function and the output processing function.
- the extraction procedure of the input processing function and the output processing function is the same as the procedure of step S705 of the first embodiment. That is, the type notification unit 206 extracts the input processing function and the output processing function associated with the threat involvement variable shown in the threat involvement variable information 214. It is assumed that the type notification unit 206 acquires the threat involvement variable information 214 in which the "variable cmd" is indicated as the threat involvement variable. In this case, the type notification unit 206 extracts the input processing function and the output processing function associated with the “variable cmd” in the program 105 of FIG.
- the type notification unit 206 is associated with the function "receiveFromHMI” represented by reference numeral 402 and the function “sendToDevice" (reference numeral 403 "cmd") indicated by reference numeral 404 from the program 105 of FIG. ) To get.
- step S803 the type notification unit 206 identifies the type of the return value of the input processing function extracted in step S802 and the type of the argument of the output processing function. Further, the type notification unit 206 notifies the type of the return value of the identified input processing function, the type of the argument of the output processing function, and the type of the argument and the return value of the countermeasure function shown in the function specific information 213. To generate. Further, the type notification unit 206 adds the generated type information 217 to the program 105 to generate the type information program 216.
- FIG. 13 shows type information 217 when "receiveFromHMI" is extracted as an input processing function and "sendToDevice” is extracted as an output processing function in step S802.
- the type information 217 in addition to the type of the argument or / and the return value of each function, the type of each function and the relationship between each function and the taint analysis are also shown. That is, the type of the input processing function "receiveFromHMI” is "input”. Further, the input processing function "receiveFromHMI” corresponds to "Source” in the taint analysis. Further, the type of the output processing function "sendToDevice” is "use”.
- the output processing function "sendToDevice” corresponds to Sink in the taint analysis.
- the type of the countermeasure function “verifyInput” is "input verification”.
- the countermeasure function "verifyImport” corresponds to "Sanitizer” in the taint analysis.
- the type information 217 of FIG. 13 it is shown that the type of the return value of the input processing function "receiveFromHMI” is "int ⁇ insecure>”.
- the type of the argument of the output processing function "sendToDevice” is "int ⁇ sure>”.
- the type of the argument of the countermeasure function "verifyInput” is "int ⁇ insecure>” and the type of the return value is "int ⁇ secure>".
- the input processing function "receiveFromHMI” is a function that returns the data input from the network. Therefore, the return value of the input processing function “receiveFromHMI” is regarded as contaminated data (taint) in the taint analysis. Therefore, the type notification unit 206 identifies the type of the return value of the input processing function "receiveFromHMI” as "int ⁇ insecure>".
- the output processing function "sendToDevice” is a function that receives uncontaminated data as an argument. Therefore, the type notification unit 206 identifies the type of the argument of the output processing function "sendToDevice” as "int ⁇ sure>".
- the argument type "int ⁇ insecure>" of the countermeasure function "verifyInput” shown in the type information 217 of FIG. 13 and the return value type “int ⁇ secure>” are the countermeasure function information of FIG. It is the type information shown in 107.
- the countermeasure function "verifyInput” is a function that receives contaminated data as an argument, verifies it, and returns the decontaminated data.
- the argument type of the countermeasure function "verifyImport” is "int ⁇ insecure>", and the return type is "int ⁇ issue>".
- the countermeasure function information 107 of FIG. 8 is used instead of the countermeasure function information 107 of FIG. 14, and the type notification unit 206 identifies the argument type and the return value type of the countermeasure function “verifyInput”. You may do so.
- step S804 the vulnerability determination unit 204 acquires the type information program 216, performs a type check using the type information 217 of the type information program 216, and determines whether or not the countermeasure processing is taken in the program 105. judge. If an error occurs in the type inspection, the vulnerability determination unit 204 identifies the location where the error occurred as a vulnerability, and if no error occurs in the type inspection, determines that the program 105 is not vulnerable.
- FIG. 16 shows the pseudo code 1002 of the program 105 shown in FIG.
- FIG. 17 shows the pseudo code 1005 of the program 901 shown in FIG.
- the operation of the type inspection by the vulnerability determination unit 204 will be described using the pseudo code 1002 and the pseudo code 1005.
- the value of the "int ⁇ insecure>" type is assigned to the variable "cmd" in the code description 1003 as the return value of the function "receive FromHMI".
- the variable "cmd” is passed as an argument of the function "sendToDevice".
- the function "sendToDevice” is supposed to receive an "int ⁇ secure>” type value as an argument. Therefore, the type of the variable cmd and the type of the argument of the function "sendToDevice" do not match, and a type error occurs.
- the vulnerability determination unit 204 determines that the code description 1004 of the pseudo code 1002 is vulnerable.
- the value of the "int ⁇ insecure>” type is assigned to the variable "cmd" in the code description 1006 as the return value of the function "receiveFromHMI".
- the variable "cmd” is passed to the function "verifyInput” as an argument.
- the function "verifyInput” is supposed to receive a value of "int ⁇ insecure>” type as an argument. Therefore, the type of the variable "cmd" and the type of the argument of the function "verifyInput" match, and the type error does not occur in the code description 1007.
- the vulnerability determination unit 204 determines that the pseudo code 1005 is not vulnerable.
- the vulnerability determination unit 204 analyzes the consistency between the return value type of the input processing function, the argument type of the output processing function, and the argument and return value type of the countermeasure function. Then, it is determined whether or not the countermeasure function is described at an appropriate position in the program, that is, between the input processing function and the output processing function.
- Embodiment 3 The above-mentioned first and second embodiments do not assume a specific development process.
- this embodiment an example of determining whether or not countermeasures against threats are taken in a program obtained by software development using a model such as model-based development or model-driven development will be described.
- the difference from the first embodiment will be mainly described. The matters not explained below are the same as those in the first embodiment.
- model-based development instead of writing specifications in natural language, specifications are generated in a format suitable for computer processing. This is called modeling, and the generated specifications are called models. Since the model is generated according to a strict form, the ambiguity of interpretation can be eliminated. It is also possible to operate the model as a simulation. It may also be possible to automatically generate source code from the model. Further, as seen in the relationship between this model and the source code, each data is associated with each other, and the software trace information described in the first embodiment can be easily obtained.
- FIG. 18 shows a simple flow of model-based development.
- modeling 1101 is performed and model 1102 is generated.
- the verification 1103 proceeds to verify the requirements or improve the design by using the model 1102.
- the operation of the program 1105 can be verified in advance by using the simulation as described above. It is also possible to mathematically prove that model 1102 meets the requirements by a method called a formal method.
- the code generation 1104 generates the program 1105 (source code). Further, information indicating the correspondence between the model 1102 and the program 1105 exists as the trace information 1106.
- FIG. 19 shows a flow in which the security design device 100 according to the first embodiment or the second embodiment is applied to the model-based development. Risk analysis is performed as part of verification 1203 in model-based development and threat list 1208 is output.
- the vulnerability determination 1207 determines the presence or absence of a vulnerability in the program 1205 (source code). Normally, the vulnerability determination 1207 is performed using only the program 1205, but in the present embodiment, the trace information 1206 and the threat list 1208 are also used.
- the trace information 1206 corresponds to the software trace information 106 of Embodiment 1.
- the threat list 1208 corresponds to the threat information 108 of the first embodiment. Note that in FIG. 19, modeling 1201 is the same as modeling 1101.
- the model 1202 is also the same as the model 1102. Further, code generation 1204 is the same as code generation 1104.
- the processor 101 shown in FIG. 1 is an IC (Integrated Circuit) that performs processing.
- the processor 101 is a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or the like.
- the main storage device 102 shown in FIG. 1 is a RAM (Random Access Memory).
- the auxiliary storage device 103 shown in FIG. 1 is a ROM (Read Only Memory), a flash memory, an HDD (Hard Disk Drive), or the like.
- the OS (Operating System) is also stored in the auxiliary storage device 103. Then, at least a part of the OS is executed by the processor 101.
- the processor 101 executes the verification program 104 while executing at least a part of the OS.
- the processor 101 executes the OS, task management, memory management, file management, communication control, and the like are performed.
- information and data indicating the processing results of the threat information acquisition unit 201, the vulnerability identification information selection unit 202, the threat involvement variable extraction unit 203, the vulnerability determination unit 204, the vulnerability information generation unit 205, and the type notification unit 206 are also stored in the auxiliary storage device 103. Then, at least a part of the OS is executed by the processor 101.
- the processor 101 executes the verification program 104 while executing at least a part of the OS.
- the processor 101 executes the OS, task management, memory management, file management, communication control, and the like are performed.
- At least one of the signal value and the variable value is stored in at least one of the register and the cache memory in the main storage device 102, the auxiliary storage device 103, and the processor 101.
- the verification program 104 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 portable recording medium in which the verification program 104 is stored may be commercially distributed.
- the "part" of the threat information acquisition unit 201, the vulnerability identification information selection unit 202, the threat involvement variable extraction unit 203, the vulnerability determination unit 204, the vulnerability information generation unit 205, and the type notification unit 206 can be referred to as a “circuit” or. It may be read as “process” or “procedure” or “process”.
- the security design device 100 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).
- 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.
- 100 security design device 101 processor, 102 main storage device, 103 auxiliary storage device, 104 verification program, 105 program, 106 software trace information, 107 countermeasure function information, 108 threat information, 109 vulnerability information, 110 vulnerability DB, 111 Input interface, 112 display interface, 113 network interface, 114 data bus, 115 vulnerability countermeasure processing information, 201 threat information acquisition unit, 202 vulnerability identification information selection unit, 203 threat involvement variable extraction unit, 204 vulnerability determination unit, 205 Vulnerability information generation unit, 206 type notification unit, 211 vulnerability identifier, 212 threat involvement element information, 213 function specific information, 214 threat involvement variable information, 215 judgment result, 216 type information program, 217 type information, 250 judgment unit, 300 system configuration diagram, 301 HMI, 302 equipment controller, 303 communication S / W, 304 field equipment, 305 transmission line, 306 transmission line, 308 control command, 309 control signal, 310 program specification diagram, 311 state transition, 312 state, 313 state, 314 state transition, 315 state transition
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
脅威情報取得部(201)は、プログラム(105)の仕様が示されるプログラム仕様書に基づくリスク分析により特定されたプログラム(105)の実行時に発生し得る脅威と、プログラム仕様書に示される要素のうち脅威の発生に関与する要素である脅威関与要素とが示される脅威情報を取得する。判定部(250)は、プログラム(105)に記述される変数のうち脅威関与要素に対応する変数を脅威関与変数として抽出し、抽出した脅威関与変数に基づきプログラム(105)を解析して脅威への対策がプログラム(105)において講じられているか否かを判定する。
Description
本発明は、セキュリティ上の脅威への対策がプログラムにおいて講じられているか否かを判定する技術に関する。
システム又は機器のセキュリティ対策は、一般に以下の手順にて実施される。まず、開発の上流工程の段階で、システム又は機器で発生し得る脅威が抽出される。次に、抽出された脅威による被害の大きさを評価するリスク分析と呼ばれるプロセスが実施される。そして、リスク分析の結果、対策すべき脅威の優先度を把握し、各脅威へのセキュリティ対策の方針を立て、開発工程の各段階でセキュリティ対策を具体化していく。例えば、データの盗聴への対策としてデータを暗号化する場合は、暗号化及び復号のロジックがソフトウェアの設計に反映される。また、暗号鍵をセキュアに保管するためのハードウェア構成がシステム設計に反映される。一方、PC(Personal Computer)への不正アクセス対策としてスクリーンロックを利用する場合は、スクリーンロックの徹底がシステムの運用マニュアルに反映される。
ソフトウェア開発の実装段階で行われるセキュリティ対策として静的解析がある、静的解析では、セキュリティ上の脅威に繋がるソフトウェアの問題である脆弱性を、ソフトウェアの実行コードを動作させず、主にソースコードを解析することによって特定する。さらに、静的解析の具体的な方法として、データフローを追跡するテイント解析と呼ばれる手法がある。
外部から入力されたデータに基づき処理を行うソフトウェアでは、想定外の入力データによって不正な処理が実行される可能性がある。テイント解析では、外部からの入力データを汚染されたデータ(テイント)と見なす。そして、テイント解析では、データが入力されてから当該データが使用されるまでのデータフローを追跡する。更に、テイント解析では、データの使用前にデータの検証処理又は/及びデータ無害化処理があるかどうかを判定する。もし、データ検証処理又は/及びデータ無害化処理がなければ、汚染されたデータがそのまま使用されることになる。データ検証処理又は/及びデータ無害化処理がない場合は、不正な処理が実行される可能性があるため、脆弱性があると判定される。一方、データ検証処理又は/及びデータ無害化処理があれば、汚染されたデータが除去されたと見なすことができ、このため、脆弱性がないと判定される。
外部から入力されたデータに基づき処理を行うソフトウェアでは、想定外の入力データによって不正な処理が実行される可能性がある。テイント解析では、外部からの入力データを汚染されたデータ(テイント)と見なす。そして、テイント解析では、データが入力されてから当該データが使用されるまでのデータフローを追跡する。更に、テイント解析では、データの使用前にデータの検証処理又は/及びデータ無害化処理があるかどうかを判定する。もし、データ検証処理又は/及びデータ無害化処理がなければ、汚染されたデータがそのまま使用されることになる。データ検証処理又は/及びデータ無害化処理がない場合は、不正な処理が実行される可能性があるため、脆弱性があると判定される。一方、データ検証処理又は/及びデータ無害化処理があれば、汚染されたデータが除去されたと見なすことができ、このため、脆弱性がないと判定される。
特許文献1では、ソースコードにおいて脆弱経路を検出する方法が示されている。
具体的には、特許文献1では、ソースコードにおいて、データが外部から入力され、外部へデータが出力される手順を定めたデータフローが抽出される。そして、抽出されたデータフローと、データベースに登録された脆弱性の発生点及び使用点とを照合することによって脆弱経路が検出される。
具体的には、特許文献1では、ソースコードにおいて、データが外部から入力され、外部へデータが出力される手順を定めたデータフローが抽出される。そして、抽出されたデータフローと、データベースに登録された脆弱性の発生点及び使用点とを照合することによって脆弱経路が検出される。
特許文献1の技術では、プログラムのみを解析し、プログラムのみから脅威を抽出する。このため、特許文献1では、脅威の抽出漏れが生じ、十分な対策を講じることができない可能性がある。
本発明は、このような課題を解決することを主な目的とする。より具体的には、本発明は、プログラムの解析のみでは抽出できない脅威に対しても対策が講じられるようにすることを主な目的とする。
本発明に係る情報処理装置は、
プログラムの仕様が示されるプログラム仕様書に基づくリスク分析により特定された前記プログラムの実行時に発生し得る脅威と、前記プログラム仕様書に示される要素のうち前記脅威の発生に関与する要素である脅威関与要素とが示される脅威情報を取得する脅威情報取得部と、
前記プログラムに記述される変数のうち前記脅威関与要素に対応する変数を脅威関与変数として抽出し、抽出した前記脅威関与変数に基づき前記プログラムを解析して前記脅威への対策が前記プログラムにおいて講じられているか否かを判定する判定部とを有する。
プログラムの仕様が示されるプログラム仕様書に基づくリスク分析により特定された前記プログラムの実行時に発生し得る脅威と、前記プログラム仕様書に示される要素のうち前記脅威の発生に関与する要素である脅威関与要素とが示される脅威情報を取得する脅威情報取得部と、
前記プログラムに記述される変数のうち前記脅威関与要素に対応する変数を脅威関与変数として抽出し、抽出した前記脅威関与変数に基づき前記プログラムを解析して前記脅威への対策が前記プログラムにおいて講じられているか否かを判定する判定部とを有する。
本発明では、プログラム仕様書に基づくリスク分析により特定された脅威への対策がプログラムにおいて講じられているか否かを判定する。このため、本発明によれば、プログラムの解析のみでは抽出できない脅威に対しても対策が講じられる。
以下、本発明の実施の形態について、図を用いて説明する。以下の実施の形態の説明及び図面において、同一の符号を付したものは、同一の部分又は相当する部分を示す。
実施の形態1.
***構成の説明***
図1は、実施の形態1に係るセキュリティ設計装置100のハードウェア構成例を示す。
セキュリティ設計装置100は、情報処理装置に相当する。また、セキュリティ設計装置100の動作手順は、情報処理方法に相当する。
***構成の説明***
図1は、実施の形態1に係るセキュリティ設計装置100のハードウェア構成例を示す。
セキュリティ設計装置100は、情報処理装置に相当する。また、セキュリティ設計装置100の動作手順は、情報処理方法に相当する。
セキュリティ設計装置100は、コンピュータである。
セキュリティ設計装置100は、プロセッサ101、主記憶装置102、補助記憶装置103、入力インターフェース111、表示インターフェース112及びネットワークインターフェース113で構成される。これらのハードウェア要素は、データバス114によって接続されている。
また、図1は、セキュリティ設計装置100の機能を実現する検証プログラム104の実行時における各データの配置例を示す。具体的には、検証プログラム104、プログラム105、ソフトウェアトレース情報106、対策関数情報107、脅威情報108、脆弱性情報109は主記憶装置102に配置される。また、脆弱性DB110は補助記憶装置103に配置される。
検証プログラム104は、情報処理プログラムに相当する。
検証プログラム104は、通常、補助記憶装置103に格納されており、実行時は、プロセッサ101によって主記憶装置102に読み込まれ、プロセッサ101により実行される。
検証プログラム104は、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205の機能を実現するプログラムである。
図1では、プロセッサ101が検証プログラム104を実行している状態を模式的に表している。つまり、図1では、プロセッサ101が、検証プログラム104を実行して、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205として動作している状態を模式的に表している。
検証プログラム104、ソフトウェアトレース情報106、対策関数情報107及び脅威情報108は、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205のいずれかにより用いられる。
プログラム105、ソフトウェアトレース情報106、対策関数情報107及び脅威情報108のうちのいずれかは、入力インターフェース111又はネットワークインターフェース113から入力されて、主記憶装置102に転送される。また、プログラム105、ソフトウェアトレース情報106、対策関数情報107及び脅威情報108のうちのいずれかは、補助記憶装置103からの読み込みによって、主記憶装置102に転送される。
脆弱性情報109は脆弱性情報生成部205から出力される。脆弱性情報109は、例えば、補助記憶装置103に格納される。また、脆弱性情報109は、表示インターフェース112に通じて表示装置に表示されてもよい。また、脆弱性情報109は、ネットワークインターフェース113を通じて外部に転送されてもよい。
セキュリティ設計装置100は、プロセッサ101、主記憶装置102、補助記憶装置103、入力インターフェース111、表示インターフェース112及びネットワークインターフェース113で構成される。これらのハードウェア要素は、データバス114によって接続されている。
また、図1は、セキュリティ設計装置100の機能を実現する検証プログラム104の実行時における各データの配置例を示す。具体的には、検証プログラム104、プログラム105、ソフトウェアトレース情報106、対策関数情報107、脅威情報108、脆弱性情報109は主記憶装置102に配置される。また、脆弱性DB110は補助記憶装置103に配置される。
検証プログラム104は、情報処理プログラムに相当する。
検証プログラム104は、通常、補助記憶装置103に格納されており、実行時は、プロセッサ101によって主記憶装置102に読み込まれ、プロセッサ101により実行される。
検証プログラム104は、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205の機能を実現するプログラムである。
図1では、プロセッサ101が検証プログラム104を実行している状態を模式的に表している。つまり、図1では、プロセッサ101が、検証プログラム104を実行して、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205として動作している状態を模式的に表している。
検証プログラム104、ソフトウェアトレース情報106、対策関数情報107及び脅威情報108は、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205のいずれかにより用いられる。
プログラム105、ソフトウェアトレース情報106、対策関数情報107及び脅威情報108のうちのいずれかは、入力インターフェース111又はネットワークインターフェース113から入力されて、主記憶装置102に転送される。また、プログラム105、ソフトウェアトレース情報106、対策関数情報107及び脅威情報108のうちのいずれかは、補助記憶装置103からの読み込みによって、主記憶装置102に転送される。
脆弱性情報109は脆弱性情報生成部205から出力される。脆弱性情報109は、例えば、補助記憶装置103に格納される。また、脆弱性情報109は、表示インターフェース112に通じて表示装置に表示されてもよい。また、脆弱性情報109は、ネットワークインターフェース113を通じて外部に転送されてもよい。
図2は、実施の形態1に係るセキュリティ設計装置100の機能構成例及びデータフロー例を示す。
前述したように、セキュリティ設計装置100は、ソフトウェアトレース情報106、脅威情報108及び脆弱性DB110を用いて、プログラム105における対策の有無を検証する。
また、セキュリティ設計装置100は、機能構成として、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205を有する。
脆弱性特定情報選択部202、脅威関与変数抽出部203及び脆弱性判定部204は、判定部250に相当する。また、脆弱性特定情報選択部202、脅威関与変数抽出部203及び脆弱性判定部204により行われる処理は判定処理に相当する。
また、セキュリティ設計装置100は、機能構成として、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204及び脆弱性情報生成部205を有する。
脆弱性特定情報選択部202、脅威関与変数抽出部203及び脆弱性判定部204は、判定部250に相当する。また、脆弱性特定情報選択部202、脅威関与変数抽出部203及び脆弱性判定部204により行われる処理は判定処理に相当する。
プログラム105は、セキュリティ設計装置100の検証対象となるプログラムである。つまり、セキュリティ設計装置100は、プログラム105の実行時に発生し得る脅威への対策がプログラム105において講じられているか否かを判定する。
本実施の形態では、制御システムの機器コントローラの通信ソフトウェア(以下、通信S/Wと表記する)にプログラム105を適用することとする。
プログラム105は、機器コントローラの動作を詳細に定義した仕様である。例えば、プログラミング言語で記述したソースコードがプログラム105に該当する。図4は、制御システムの機器コントローラの通信S/W303、すなわち、プログラム105の例を示す。
プログラム105はソフトウェア開発の実装段階で生成されるものである。通常のソフトウェア開発では、実装に先立って、例えばシステム設計の段階がある。そして、システム設計の段階で、システム構成やシステムの概略的な動作が定義される。
本実施の形態では、制御システムの機器コントローラの通信ソフトウェア(以下、通信S/Wと表記する)にプログラム105を適用することとする。
プログラム105は、機器コントローラの動作を詳細に定義した仕様である。例えば、プログラミング言語で記述したソースコードがプログラム105に該当する。図4は、制御システムの機器コントローラの通信S/W303、すなわち、プログラム105の例を示す。
プログラム105はソフトウェア開発の実装段階で生成されるものである。通常のソフトウェア開発では、実装に先立って、例えばシステム設計の段階がある。そして、システム設計の段階で、システム構成やシステムの概略的な動作が定義される。
図3は、制御システムのシステム構成図300及びプログラム仕様図310の例を示す。システム構成図300とプログラム仕様図310は、プログラム仕様書の例である。プログラム仕様書は、プログラムの仕様が示される情報である。プログラム仕様書は、プログラム105のコーディングに先立って生成されるソフトウェア開発成果物である。
本実施の形態に係る制御システムは、HMI(Human Machine Interface)301、機器コントローラ302及びフィールド機器304で構成される。HMI301と機器コントローラ302は伝送路305で接続され、機器コントローラ302とフィールド機器304は伝送路306で接続される。
HMI301は、運転員が制御システムの監視制御を行うための端末である。HMI301における運転員による操作に従い、HMI301から機器コントローラ302に対して、伝送路305を介して、START、STOP及びREADのいずれかの制御コマンド308が送信される。また、HMI301は、機器コントローラ302から、レスポンスとしてセンサ情報を受信する。
機器コントローラ302は、HMI301からの指示に従いフィールド機器304を制御する。機器コントローラ302の送受信機能は、通信S/W303によって実現されている。より具体的には、通信S/W303は、HMI301から伝送路305を介して送信された制御コマンド308を受信する。また、通信S/W303は、HMI301から受信した制御コマンド308に従い、フィールド機器304にON、OFFいずれかの制御信号309を送信する。また、通信S/W303は、フィールド機器304から送信されるセンサ情報を受信する。更に、通信S/W303は、制御コマンド308に対するレスポンスとして、センサ情報をHMI301に送信する。
通信S/W303は、ソフトウェア開発の段階に従って仕様化、詳細化されていく。例えば、システム構成図300が生成されて通信S/W303の動作の概要が定義され、次に、プログラム仕様図310が生成されて通信S/W303のプログラム仕様が定義される。そして、実装段階でさらに詳細化されて、ソースコードであるプログラム105が生成される。
HMI301は、運転員が制御システムの監視制御を行うための端末である。HMI301における運転員による操作に従い、HMI301から機器コントローラ302に対して、伝送路305を介して、START、STOP及びREADのいずれかの制御コマンド308が送信される。また、HMI301は、機器コントローラ302から、レスポンスとしてセンサ情報を受信する。
機器コントローラ302は、HMI301からの指示に従いフィールド機器304を制御する。機器コントローラ302の送受信機能は、通信S/W303によって実現されている。より具体的には、通信S/W303は、HMI301から伝送路305を介して送信された制御コマンド308を受信する。また、通信S/W303は、HMI301から受信した制御コマンド308に従い、フィールド機器304にON、OFFいずれかの制御信号309を送信する。また、通信S/W303は、フィールド機器304から送信されるセンサ情報を受信する。更に、通信S/W303は、制御コマンド308に対するレスポンスとして、センサ情報をHMI301に送信する。
通信S/W303は、ソフトウェア開発の段階に従って仕様化、詳細化されていく。例えば、システム構成図300が生成されて通信S/W303の動作の概要が定義され、次に、プログラム仕様図310が生成されて通信S/W303のプログラム仕様が定義される。そして、実装段階でさらに詳細化されて、ソースコードであるプログラム105が生成される。
プログラム仕様図310は、状態遷移図である。プログラム仕様図310は、状態遷移311、状態312、状態313、状態遷移314及び状態遷移315で構成されている。
状態312は、SYSTEM_OFFのラベルを持つ状態である。状態313は、SYSTEM_ONのラベルを持つ状態である。状態遷移311は、状態312から状態313への状態遷移である。状態遷移314は、状態313から状態312への状態遷移である。状態遷移315は、状態313から状態313への状態遷移である。
状態遷移311は、状態がSYSTEM_OFFであるとき、「HMIから制御コマンドSTARTを受信」という条件が満たされれば「フィールド機器に制御信号ONを送信」という処理が実行され、状態がSYSTEM_ONに遷移することを意味する。これは、HMI301から制御コマンドSTARTを受信すると、フィールド機器304に制御信号ONを送信するという、機器コントローラ302の通信S/W303の動作を定義している。
状態遷移314は、状態がSYSTEM_ONであるとき、「HMIから制御コマンドSTOPを受信」という条件が満たされれば「フィールド機器に制御信号OFFを送信」という処理が実行され、状態がSYSTEM_OFFに遷移することを意味する。これは、HMI301から制御コマンドSTOPを受信すると、フィールド機器304に制御信号OFFを送信するという、機器コントローラ302の通信S/W303の動作を定義している。
状態遷移315は、状態がSYSTEM_ONであるとき、「HMIから制御コマンドREADを受信」という条件が満たされれば「フィールド機器からセンサ情報を読込」と「HMIにセンサ情報を送信」の2個の処理が実行され、状態がSYSTEM_ONに遷移する、すなわち、状態がSYSTEM_ONのまま変化しないことを意味する。これは、HMI301から制御コマンドREADを受信すると、フィールド機器304から読み込んだセンサ情報をHMI301に送信するという、機器コントローラ302の通信S/W303の動作を定義している。
状態312は、SYSTEM_OFFのラベルを持つ状態である。状態313は、SYSTEM_ONのラベルを持つ状態である。状態遷移311は、状態312から状態313への状態遷移である。状態遷移314は、状態313から状態312への状態遷移である。状態遷移315は、状態313から状態313への状態遷移である。
状態遷移311は、状態がSYSTEM_OFFであるとき、「HMIから制御コマンドSTARTを受信」という条件が満たされれば「フィールド機器に制御信号ONを送信」という処理が実行され、状態がSYSTEM_ONに遷移することを意味する。これは、HMI301から制御コマンドSTARTを受信すると、フィールド機器304に制御信号ONを送信するという、機器コントローラ302の通信S/W303の動作を定義している。
状態遷移314は、状態がSYSTEM_ONであるとき、「HMIから制御コマンドSTOPを受信」という条件が満たされれば「フィールド機器に制御信号OFFを送信」という処理が実行され、状態がSYSTEM_OFFに遷移することを意味する。これは、HMI301から制御コマンドSTOPを受信すると、フィールド機器304に制御信号OFFを送信するという、機器コントローラ302の通信S/W303の動作を定義している。
状態遷移315は、状態がSYSTEM_ONであるとき、「HMIから制御コマンドREADを受信」という条件が満たされれば「フィールド機器からセンサ情報を読込」と「HMIにセンサ情報を送信」の2個の処理が実行され、状態がSYSTEM_ONに遷移する、すなわち、状態がSYSTEM_ONのまま変化しないことを意味する。これは、HMI301から制御コマンドREADを受信すると、フィールド機器304から読み込んだセンサ情報をHMI301に送信するという、機器コントローラ302の通信S/W303の動作を定義している。
以上のように、機器コントローラ302の通信S/W303の開発においては、開発工程の各段階に応じてシステム構成図300、プログラム仕様図310及びプログラム105のような仕様が生成され、それらは互いに対応付けられる。ソフトウェアのライフサイクルにおいて、各成果物が互いに対応付けられ追跡可能である性質はトレーサビリティと呼ばれる。これにより、例えば要求が設計、実装に正しく反映されていることが保証される。
ソフトウェアトレース情報106は、相互に関連するプログラム105の要素とプログラム仕様書の要素とが対応付けられて示される情報である。
図5は、本実施の形態に係るソフトウェアトレース情報106の例を示す。
ソフトウェアトレース情報106は、システム設計とプログラム設計と実装の項目で構成される。
ソフトウェアトレース情報106は、ソフトウェア開発の各段階で生成される成果物を互いに対応付ける情報である。例えば、番号1の行から、各段階の成果物がシステム構成図300、プログラム仕様図310及びプログラム105であることがわかる。また、番号2の行から、システム構成図300の制御コマンドがプログラム仕様図310の制御コマンドに対応し、また、プログラム105の変数cmdに対応することがわかる。
図5は、本実施の形態に係るソフトウェアトレース情報106の例を示す。
ソフトウェアトレース情報106は、システム設計とプログラム設計と実装の項目で構成される。
ソフトウェアトレース情報106は、ソフトウェア開発の各段階で生成される成果物を互いに対応付ける情報である。例えば、番号1の行から、各段階の成果物がシステム構成図300、プログラム仕様図310及びプログラム105であることがわかる。また、番号2の行から、システム構成図300の制御コマンドがプログラム仕様図310の制御コマンドに対応し、また、プログラム105の変数cmdに対応することがわかる。
脅威情報108は、例えば、図6に示す情報である。脅威情報108は、開発対象のソフトウェアが搭載される機器、その機器が利用されるシステムに対するセキュリティの脅威が定義された情報である。図6の脅威情報108は、図3のシステム構成図300に基づくリスク分析によって抽出されるセキュリティ脅威の一覧を示している。
脅威情報108は、脅威と情報資産と脆弱性の項目で構成される。
「脅威」は、プログラム105の実行時に発生し得る脅威である。脅威は、プログラム仕様書(本例では、システム構成図300)に基づくリスク分析により特定された脅威である。ユーザがプログラム仕様書を参照したリスク分析を行って脅威の特定を行ってもよいし、特定の分析ツールにプログラム仕様書に基づくリスク分析を行わせて脅威の特定を行わせてもよい。
「情報資産」は、プログラム仕様書に示される要素のうち脅威の発生に関与する要素である。脅威情報108に示される情報資産を脅威関与要素にともいう。
「脆弱性」は、脅威を発生させる脆弱性であり、プログラム105に存在する脆弱性である。図7の例では、脆弱性は、CWE(Common Weakness Enumeration)と呼ばれる脆弱性の識別子により表現されている。図7の例からは、「HMI-機器コントローラ間の制御コマンドの改ざんによるフィールド機器の停止」という脅威があり、当該脅威の発生に関与する情報資産が「制御コマンド」であること、また、当該脅威を発生させる脆弱性が「CWE-20」であることがわかる。なお、脆弱性は、CWE以外の形式で表現することも可能である。
脅威情報108は、脅威と情報資産と脆弱性の項目で構成される。
「脅威」は、プログラム105の実行時に発生し得る脅威である。脅威は、プログラム仕様書(本例では、システム構成図300)に基づくリスク分析により特定された脅威である。ユーザがプログラム仕様書を参照したリスク分析を行って脅威の特定を行ってもよいし、特定の分析ツールにプログラム仕様書に基づくリスク分析を行わせて脅威の特定を行わせてもよい。
「情報資産」は、プログラム仕様書に示される要素のうち脅威の発生に関与する要素である。脅威情報108に示される情報資産を脅威関与要素にともいう。
「脆弱性」は、脅威を発生させる脆弱性であり、プログラム105に存在する脆弱性である。図7の例では、脆弱性は、CWE(Common Weakness Enumeration)と呼ばれる脆弱性の識別子により表現されている。図7の例からは、「HMI-機器コントローラ間の制御コマンドの改ざんによるフィールド機器の停止」という脅威があり、当該脅威の発生に関与する情報資産が「制御コマンド」であること、また、当該脅威を発生させる脆弱性が「CWE-20」であることがわかる。なお、脆弱性は、CWE以外の形式で表現することも可能である。
脆弱性DB110では、図7に示される脆弱性対策処理情報115が格納されている。
脆弱性対策処理情報115は、脆弱性と対策処理の項目で構成される。
「脆弱性」は、脅威情報108に示される脆弱性である。
「対策処理」は、脅威への対策を実現する処理である。具体的には、「対策処理」には、脅威を排除するための処理が示される。
図7の脆弱性対策処理情報115では、例えば、CWE-20の脆弱性に対しては、「入力検証」により脅威が排除される。
脆弱性対策処理情報115は、脆弱性と対策処理の項目で構成される。
「脆弱性」は、脅威情報108に示される脆弱性である。
「対策処理」は、脅威への対策を実現する処理である。具体的には、「対策処理」には、脅威を排除するための処理が示される。
図7の脆弱性対策処理情報115では、例えば、CWE-20の脆弱性に対しては、「入力検証」により脅威が排除される。
対策関数情報107は、例えば、図8に示す情報である。対策関数情報107は、対策処理とライブラリと対策関数の項目で構成される。
「対策処理」は、脆弱性対策処理情報115に示される対策処理である。
「ライブラリ」は、プログラム105が使用するライブラリを示す。
「対策関数」は、プログラム105が使用するライブラリにおいて対策処理を実現する関数を示す。具体的には、脅威を排除するための関数である。
「対策処理」は、脆弱性対策処理情報115に示される対策処理である。
「ライブラリ」は、プログラム105が使用するライブラリを示す。
「対策関数」は、プログラム105が使用するライブラリにおいて対策処理を実現する関数を示す。具体的には、脅威を排除するための関数である。
図2に戻り、脅威情報取得部201は、脅威情報108を取得する。
そして、脅威情報取得部201は、脅威情報108から脆弱性識別子211及び脅威関与要素情報212を生成する。また、脅威情報取得部201は、脆弱性識別子211を脆弱性特定情報選択部202に出力し、脅威関与要素情報212を脅威関与変数抽出部203に出力する。
具体的には、脅威情報取得部201は、脅威情報108に示される脆弱性(例えば、「CWE-20」)を抽出する。また、脅威情報取得部201は、抽出した脆弱性を通知する脆弱性識別子211を生成し、脆弱性識別子211を脆弱性特定情報選択部202に出力する。また、脅威情報取得部201は、脅威情報108に示される情報資産(例えば、「制御コマンド」)を通知する脅威関与要素情報212を生成する。そして、脅威情報取得部201は、脅威関与要素情報212を脅威関与変数抽出部203に出力する。
脅威情報取得部201で行われる処理は、脅威情報取得処理に相当する。
そして、脅威情報取得部201は、脅威情報108から脆弱性識別子211及び脅威関与要素情報212を生成する。また、脅威情報取得部201は、脆弱性識別子211を脆弱性特定情報選択部202に出力し、脅威関与要素情報212を脅威関与変数抽出部203に出力する。
具体的には、脅威情報取得部201は、脅威情報108に示される脆弱性(例えば、「CWE-20」)を抽出する。また、脅威情報取得部201は、抽出した脆弱性を通知する脆弱性識別子211を生成し、脆弱性識別子211を脆弱性特定情報選択部202に出力する。また、脅威情報取得部201は、脅威情報108に示される情報資産(例えば、「制御コマンド」)を通知する脅威関与要素情報212を生成する。そして、脅威情報取得部201は、脅威関与要素情報212を脅威関与変数抽出部203に出力する。
脅威情報取得部201で行われる処理は、脅威情報取得処理に相当する。
脆弱性特定情報選択部202は、脅威情報取得部201から脆弱性識別子211を取得する。また、脆弱性特定情報選択部202は、プログラム105及び対策関数情報107を取得する。そして、脆弱性特定情報選択部202は、脆弱性識別子211に基づき脆弱性DB110内の脆弱性対策処理情報115を検索する。この結果、脆弱性特定情報選択部202は、脆弱性識別子211で通知された脆弱性に対する対策処理を特定する。また、脆弱性特定情報選択部202は、プログラム105を解析してプログラム105で用いられるライブラリを特定する。そして、脆弱性特定情報選択部202は、特定した対策処理とライブラリとに対応する対策関数を対策関数情報107から抽出する。そして、脆弱性特定情報選択部202は、対策関数情報107から抽出した対策関数を通知する関数特定情報213を生成し、生成した関数特定情報213を脆弱性判定部204に出力する。
脅威関与変数抽出部203は、ソフトウェアトレース情報106と脅威関与要素情報212を取得する。
そして、脅威関与変数抽出部203は、脅威関与要素情報212に示される情報資産(脅威関与要素)とソフトウェアトレース情報106において対応付けられているプログラム105の要素を抽出する。より具体的には、脅威関与変数抽出部203は、脅威関与要素情報212に示される情報資産(脅威関与要素)とソフトウェアトレース情報106において対応付けられているプログラム105の変数を抽出する。なお、脅威関与変数抽出部203が抽出する変数を脅威関与変数という。
脅威関与変数抽出部203は、抽出した脅威関与変数を通知する脅威関与変数情報214を生成する。そして、脅威関与変数抽出部203は、生成した脅威関与変数情報214を脆弱性判定部204に出力する。
そして、脅威関与変数抽出部203は、脅威関与要素情報212に示される情報資産(脅威関与要素)とソフトウェアトレース情報106において対応付けられているプログラム105の要素を抽出する。より具体的には、脅威関与変数抽出部203は、脅威関与要素情報212に示される情報資産(脅威関与要素)とソフトウェアトレース情報106において対応付けられているプログラム105の変数を抽出する。なお、脅威関与変数抽出部203が抽出する変数を脅威関与変数という。
脅威関与変数抽出部203は、抽出した脅威関与変数を通知する脅威関与変数情報214を生成する。そして、脅威関与変数抽出部203は、生成した脅威関与変数情報214を脆弱性判定部204に出力する。
脆弱性判定部204は、プログラム105と関数特定情報213と脅威関与変数情報214を取得する。
そして、脆弱性判定部204は、プログラム105内の適切な箇所に脅威関与変数情報214に示される対策関数が記述されているか否かを判定する。プログラム105内の適切な箇所に対策関数が記述されている場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていると判定する。一方で、プログラム105内の適切な箇所に対策関数が記述されていない場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていないと判定する。
より具体的には、脆弱性判定部204は、脅威関与変数情報214に示す脅威関与変数と対応付けられた入力処理関数と脅威関与変数と対応付けられた出力処理関数とを抽出する。そして、脆弱性判定部204は、抽出した入力処理関数と出力処理関数との間に対策関数が記述されているか否かを判定する。入力処理関数と出力処理関数との間に対策関数が記述されている場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていると判定する。一方で、入力処理関数と出力処理関数との間に対策関数が記述されていない場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていないと判定する。
そして、脆弱性判定部204は、判定結果215を脆弱性情報生成部205に出力する。
そして、脆弱性判定部204は、プログラム105内の適切な箇所に脅威関与変数情報214に示される対策関数が記述されているか否かを判定する。プログラム105内の適切な箇所に対策関数が記述されている場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていると判定する。一方で、プログラム105内の適切な箇所に対策関数が記述されていない場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていないと判定する。
より具体的には、脆弱性判定部204は、脅威関与変数情報214に示す脅威関与変数と対応付けられた入力処理関数と脅威関与変数と対応付けられた出力処理関数とを抽出する。そして、脆弱性判定部204は、抽出した入力処理関数と出力処理関数との間に対策関数が記述されているか否かを判定する。入力処理関数と出力処理関数との間に対策関数が記述されている場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていると判定する。一方で、入力処理関数と出力処理関数との間に対策関数が記述されていない場合は、脆弱性判定部204は、プログラム105において脅威への対策が講じられていないと判定する。
そして、脆弱性判定部204は、判定結果215を脆弱性情報生成部205に出力する。
脆弱性情報生成部205は、判定結果215を取得する。
そして、脆弱性情報生成部205は、判定結果215から脆弱性情報109を生成し、脆弱性情報109を出力する。
前述したように、脆弱性情報生成部205は、例えば脆弱性情報109を補助記憶装置103に出力する。また、脆弱性情報生成部205は、ネットワークインターフェース113を介して脆弱性情報109を外部に出力してもよいし、表示インターフェース112を介して脆弱性情報109を表示装置に出力してもよい。
そして、脆弱性情報生成部205は、判定結果215から脆弱性情報109を生成し、脆弱性情報109を出力する。
前述したように、脆弱性情報生成部205は、例えば脆弱性情報109を補助記憶装置103に出力する。また、脆弱性情報生成部205は、ネットワークインターフェース113を介して脆弱性情報109を外部に出力してもよいし、表示インターフェース112を介して脆弱性情報109を表示装置に出力してもよい。
***動作の説明***
次に、実施の形態1に係るセキュリティ設計装置100の動作例を説明する。
図10は、実施の形態1に係るセキュリティ設計装置100の動作例を表すフローチャートである。
次に、実施の形態1に係るセキュリティ設計装置100の動作例を説明する。
図10は、実施の形態1に係るセキュリティ設計装置100の動作例を表すフローチャートである。
先ず、ステップS701で、脅威情報取得部201が脅威情報108を取得する。
次に、ステップS702で、脅威情報取得部201が脅威情報108から脆弱性識別子211及び脅威関与要素情報212を生成する。
次に、ステップS703で、脆弱性特定情報選択部202がプログラム105と脆弱性対策処理情報115とを参照して対策関数情報107から対策関数を抽出する。
次に、ステップS704で、脅威関与変数抽出部203が脅威関与要素情報212とソフトウェアトレース情報106を参照して脅威関与変数を抽出する。
次に、ステップS705で、脆弱性判定部204が脅威関与変数情報214を参照してプログラム105から入力処理関数と出力処理関数を抽出する。
次に、ステップS706で、脆弱性判定部204が入力処理関数及び出力処理関数を抽出し、抽出した入力処理関数及び出力処理関数と関数特定情報213に示される対策関数とに基づきプログラム105において対策処理が講じられているか否かを判定する。
最後に、ステップS707で、脆弱性情報生成部205が脆弱性判定部204の判定結果215を整形し、脆弱性情報109を出力する。
次に、図10の各ステップの詳細を説明する。
(ステップS701)
脅威情報取得部201は、図6に示す脅威情報108を取得する。
脅威情報取得部201は、図6に示す脅威情報108を取得する。
(ステップS702)
脅威情報取得部201は、脅威情報108から、各脅威に対応する情報資産の値及び脆弱性の値を抽出する。
図6の脅威情報108では、各行に、脅威、情報資産及び脆弱性の組が記載されている。脅威情報取得部201は、1行ずつ、情報資産の値と脆弱性の値を抽出する。そして、脅威情報取得部201は、抽出した情報資産の値を示す脅威関与要素情報212を脅威関与変数抽出部203に出力する。また、脅威情報取得部201は、抽出した脆弱性の値を示す脆弱性識別子211を脆弱性特定情報選択部202に出力する。
図6の例では、脅威情報取得部201は、情報資産の欄から「制御コマンド」を抽出し、「制御コマンド」を脅威関与要素として示す脅威関与要素情報212を脅威関与変数抽出部203に出力する。また、脆弱性特定情報選択部202は、脆弱性の欄から「CWE-20」を抽出し、「CWE-20」を示す脆弱性識別子211を脆弱性特定情報選択部202に出力する。脅威情報取得部201は、番号2以降の行についても同様にして脆弱性識別子211及び脅威関与要素情報212を出力する。
脅威情報取得部201は、脅威情報108から、各脅威に対応する情報資産の値及び脆弱性の値を抽出する。
図6の脅威情報108では、各行に、脅威、情報資産及び脆弱性の組が記載されている。脅威情報取得部201は、1行ずつ、情報資産の値と脆弱性の値を抽出する。そして、脅威情報取得部201は、抽出した情報資産の値を示す脅威関与要素情報212を脅威関与変数抽出部203に出力する。また、脅威情報取得部201は、抽出した脆弱性の値を示す脆弱性識別子211を脆弱性特定情報選択部202に出力する。
図6の例では、脅威情報取得部201は、情報資産の欄から「制御コマンド」を抽出し、「制御コマンド」を脅威関与要素として示す脅威関与要素情報212を脅威関与変数抽出部203に出力する。また、脆弱性特定情報選択部202は、脆弱性の欄から「CWE-20」を抽出し、「CWE-20」を示す脆弱性識別子211を脆弱性特定情報選択部202に出力する。脅威情報取得部201は、番号2以降の行についても同様にして脆弱性識別子211及び脅威関与要素情報212を出力する。
(ステップS703)
脆弱性特定情報選択部202は、脅威情報取得部201から脆弱性識別子211を取得する。また、脆弱性特定情報選択部202は、プログラム105及び対策関数情報107を取得する。そして、脆弱性特定情報選択部202は、脆弱性識別子211に基づき脆弱性DB110内の脆弱性対策処理情報115を検索し、対策処理を特定する。
例えば、「CWE-20」を示す脆弱性識別子211を取得した場合は、脆弱性特定情報選択部202は、「CWE-20」をキーにして図7に例示する脆弱性対策処理情報115を検索して、「CWE-20」に対応する対策処理として「入力検証」を抽出する。
また、脆弱性特定情報選択部202は、プログラム105を解析して、プログラム105で用いられるライブラリを特定する。ここでは、脆弱性特定情報選択部202は、プログラム105で用いられるライブラリとして「SSL」を特定したとする。脆弱性特定情報選択部202は、対策関数情報107を参照し、「入力検証」及び「SSL」に対応する対策関数を抽出する。図8の対策関数情報107では、脆弱性特定情報選択部202は、対策関数として「verifyInput」を抽出する。
そして、脆弱性特定情報選択部202は、対策関数「verifyInput」を示す関数特定情報213を脆弱性判定部204に出力する。
脆弱性特定情報選択部202は、脅威情報取得部201から脆弱性識別子211を取得する。また、脆弱性特定情報選択部202は、プログラム105及び対策関数情報107を取得する。そして、脆弱性特定情報選択部202は、脆弱性識別子211に基づき脆弱性DB110内の脆弱性対策処理情報115を検索し、対策処理を特定する。
例えば、「CWE-20」を示す脆弱性識別子211を取得した場合は、脆弱性特定情報選択部202は、「CWE-20」をキーにして図7に例示する脆弱性対策処理情報115を検索して、「CWE-20」に対応する対策処理として「入力検証」を抽出する。
また、脆弱性特定情報選択部202は、プログラム105を解析して、プログラム105で用いられるライブラリを特定する。ここでは、脆弱性特定情報選択部202は、プログラム105で用いられるライブラリとして「SSL」を特定したとする。脆弱性特定情報選択部202は、対策関数情報107を参照し、「入力検証」及び「SSL」に対応する対策関数を抽出する。図8の対策関数情報107では、脆弱性特定情報選択部202は、対策関数として「verifyInput」を抽出する。
そして、脆弱性特定情報選択部202は、対策関数「verifyInput」を示す関数特定情報213を脆弱性判定部204に出力する。
(ステップS704)
脅威関与変数抽出部203は、脅威関与要素情報212を脅威情報取得部201から取得する。また、脅威関与変数抽出部203は、ソフトウェアトレース情報106を取得する。
そして、脅威関与変数抽出部203は、脅威関与要素情報212に示される情報資産(脅威関与要素)に対応する変数(脅威関与変数)を抽出する。
ここで、脅威関与変数抽出部203は、情報資産「制御コマンド」が示される脅威関与要素情報212を取得したものとする。脅威関与変数抽出部203は、図5のソフトウェアトレース情報106を参照して、「制御コマンド」に対応する「実装」の欄の値である「変数cmd」を脅威関与変数として抽出する。
脅威関与変数抽出部203は、抽出した脅威関与変数である「変数cmd」が示される脅威関与変数情報214を脆弱性判定部204に出力する。
脅威関与変数抽出部203は、脅威関与要素情報212を脅威情報取得部201から取得する。また、脅威関与変数抽出部203は、ソフトウェアトレース情報106を取得する。
そして、脅威関与変数抽出部203は、脅威関与要素情報212に示される情報資産(脅威関与要素)に対応する変数(脅威関与変数)を抽出する。
ここで、脅威関与変数抽出部203は、情報資産「制御コマンド」が示される脅威関与要素情報212を取得したものとする。脅威関与変数抽出部203は、図5のソフトウェアトレース情報106を参照して、「制御コマンド」に対応する「実装」の欄の値である「変数cmd」を脅威関与変数として抽出する。
脅威関与変数抽出部203は、抽出した脅威関与変数である「変数cmd」が示される脅威関与変数情報214を脆弱性判定部204に出力する。
(ステップS705)
脆弱性判定部204は、脅威関与変数抽出部203から脅威関与変数情報214を取得する。また、脆弱性情報生成部205はプログラム105を取得する。
脆弱性判定部204は、脅威関与変数情報214に示される脅威関与変数と対応付けられた入力処理関数と出力処理関数を抽出する。
脆弱性判定部204が「変数cmd」が示される脅威関与変数情報214を取得したとする。この場合に、脆弱性判定部204は、図4のプログラム105において「変数cmd」と対応付けられている入力処理関数と出力処理関数を抽出する。具体的には、脆弱性判定部204は、図4のプログラム105から、符号402で示される関数「receiveFromHMI」と符号404で示される関数「sendToDevice」(符号403の「cmd」と対応付けられている)を取得する。
なお、符号402から符号404の範囲が、変数cmdが入力されてから変数cmdが使用されるまでのデータフローを表している。
脆弱性判定部204は、脅威関与変数抽出部203から脅威関与変数情報214を取得する。また、脆弱性情報生成部205はプログラム105を取得する。
脆弱性判定部204は、脅威関与変数情報214に示される脅威関与変数と対応付けられた入力処理関数と出力処理関数を抽出する。
脆弱性判定部204が「変数cmd」が示される脅威関与変数情報214を取得したとする。この場合に、脆弱性判定部204は、図4のプログラム105において「変数cmd」と対応付けられている入力処理関数と出力処理関数を抽出する。具体的には、脆弱性判定部204は、図4のプログラム105から、符号402で示される関数「receiveFromHMI」と符号404で示される関数「sendToDevice」(符号403の「cmd」と対応付けられている)を取得する。
なお、符号402から符号404の範囲が、変数cmdが入力されてから変数cmdが使用されるまでのデータフローを表している。
(ステップS706)
脆弱性判定部204は、脆弱性特定情報選択部202から関数特定情報213を取得する。
脆弱性判定部204は、ステップS705で抽出した入力処理関数と出力処理関数との間に関数特定情報213に示される対策関数が記述されているか否かを判定する。
脆弱性判定部204は、ステップS705で入力処理関数として関数「receiveFromHMI」を抽出し、出力処理関数として関数「sendToDevice」を抽出したものとする。また、脆弱性判定部204は、対策関数として「verifyInput」が示される関数特定情報213を取得したものとする。
脆弱性判定部204は、プログラム105の関数「receiveFromHMI」(符号402)と関数「sendToDevice」(符号404)との間に、対策関数「verifyInput」が記述されているか否かを判定する。
図4のプログラム105では、関数「receiveFromHMI」(符号402)と関数「sendToDevice」(符号404)との間に、対策関数「verifyInput」は記述されていない。このため、脆弱性判定部204は、プログラム105には脅威情報108に示される脅威への対策が講じられていないと判定する。つまり、脆弱性判定部204は、プログラム105には脆弱性が存在すると判定する。
一方で、図9に示すプログラム901では、関数「receiveFromHMI」(符号402)と関数「sendToDevice」(符号404)との間に、対策関数「verifyInput」(符号405)が記述されている。このため、脆弱性判定部204は、プログラム105には脅威情報108に示される脅威への対策が講じられていると判定する。つまり、脆弱性判定部204は、プログラム901には脆弱性がないと判定する。
脆弱性判定部204は、判定結果215を脆弱性情報生成部205に出力する。脆弱性判定部204は、プログラム105において脅威への対策が講じられていないと判定した場合は、例えば、プログラム105の名称と、脅威と、脅威関与要素である情報資産と、脆弱性識別子と、脅威関与変数と、脆弱性のある関数と、脆弱性のある関数が記述されている箇所が示される判定結果215を出力する。一方、プログラム105において脅威への対策が講じられていると判定した場合は、脆弱性判定部204は、例えば、プログラム105の名称と、脅威と、対策済みである旨のメッセージが示される判定結果215を出力する。なお、プログラム105において脅威への対策が講じられていると判定した場合は、脆弱性判定部204は判定結果215を出力しなくてもよい。
脆弱性判定部204は、脆弱性特定情報選択部202から関数特定情報213を取得する。
脆弱性判定部204は、ステップS705で抽出した入力処理関数と出力処理関数との間に関数特定情報213に示される対策関数が記述されているか否かを判定する。
脆弱性判定部204は、ステップS705で入力処理関数として関数「receiveFromHMI」を抽出し、出力処理関数として関数「sendToDevice」を抽出したものとする。また、脆弱性判定部204は、対策関数として「verifyInput」が示される関数特定情報213を取得したものとする。
脆弱性判定部204は、プログラム105の関数「receiveFromHMI」(符号402)と関数「sendToDevice」(符号404)との間に、対策関数「verifyInput」が記述されているか否かを判定する。
図4のプログラム105では、関数「receiveFromHMI」(符号402)と関数「sendToDevice」(符号404)との間に、対策関数「verifyInput」は記述されていない。このため、脆弱性判定部204は、プログラム105には脅威情報108に示される脅威への対策が講じられていないと判定する。つまり、脆弱性判定部204は、プログラム105には脆弱性が存在すると判定する。
一方で、図9に示すプログラム901では、関数「receiveFromHMI」(符号402)と関数「sendToDevice」(符号404)との間に、対策関数「verifyInput」(符号405)が記述されている。このため、脆弱性判定部204は、プログラム105には脅威情報108に示される脅威への対策が講じられていると判定する。つまり、脆弱性判定部204は、プログラム901には脆弱性がないと判定する。
脆弱性判定部204は、判定結果215を脆弱性情報生成部205に出力する。脆弱性判定部204は、プログラム105において脅威への対策が講じられていないと判定した場合は、例えば、プログラム105の名称と、脅威と、脅威関与要素である情報資産と、脆弱性識別子と、脅威関与変数と、脆弱性のある関数と、脆弱性のある関数が記述されている箇所が示される判定結果215を出力する。一方、プログラム105において脅威への対策が講じられていると判定した場合は、脆弱性判定部204は、例えば、プログラム105の名称と、脅威と、対策済みである旨のメッセージが示される判定結果215を出力する。なお、プログラム105において脅威への対策が講じられていると判定した場合は、脆弱性判定部204は判定結果215を出力しなくてもよい。
(ステップS707)
脆弱性情報生成部205は、脆弱性判定部204から判定結果215を取得する。そして、脆弱性情報生成部205は、判定結果215を整形し、整形後の判定結果215を脆弱性情報109として出力する。
図11は、脆弱性情報109の例を示す。
図11において、「脅威」、「情報資産」及び「脆弱性」の値は、脅威情報108の値と同じである。「プログラム」の項目には、プログラム105の名称が記載される。「開始行:終了行」には、「関数」の項目に示される関数が記述されているプログラム105の行が記載される。「変数」には脅威関与変数が記載される。「関数」には脆弱性のある関数が記載される。
脆弱性情報生成部205は、脆弱性判定部204から判定結果215を取得する。そして、脆弱性情報生成部205は、判定結果215を整形し、整形後の判定結果215を脆弱性情報109として出力する。
図11は、脆弱性情報109の例を示す。
図11において、「脅威」、「情報資産」及び「脆弱性」の値は、脅威情報108の値と同じである。「プログラム」の項目には、プログラム105の名称が記載される。「開始行:終了行」には、「関数」の項目に示される関数が記述されているプログラム105の行が記載される。「変数」には脅威関与変数が記載される。「関数」には脆弱性のある関数が記載される。
なお、以上では、説明の簡明のために、脅威情報108の番号1の行に示される脅威に対する対策の有無を検証する例を説明した。セキュリティ設計装置100は、脅威情報108の各行に対して図7のステップS702以降の処理を行う。
また、複数のプログラム105を検証対象とする場合は、セキュリティ設計装置100は、各プログラム105に対して図7のステップS701以降の処理を行う。
対策関数が複数存在する場合、脅威関与変数が複数存在する場合も、セキュリティ設計装置100は適宜該当する処理を繰り返し行う。
また、複数のプログラム105を検証対象とする場合は、セキュリティ設計装置100は、各プログラム105に対して図7のステップS701以降の処理を行う。
対策関数が複数存在する場合、脅威関与変数が複数存在する場合も、セキュリティ設計装置100は適宜該当する処理を繰り返し行う。
***実施の形態の効果の説明***
以上のように、本実施の形態では、ソフトウェア開発の上流段階で行われるリスク分析で特定された脅威への対策が、下流段階で生成されたプログラムにおいて講じられているか否かを判定する。
このため、本実施の形態によれば、プログラムの解析のみでは抽出できない脅威に対する対策の有無を判定することできる。そして、本実施の形態によれば、判定結果に基づき、プログラムの解析のみでは抽出できない脅威に対する対策を講じることができる。
以上のように、本実施の形態では、ソフトウェア開発の上流段階で行われるリスク分析で特定された脅威への対策が、下流段階で生成されたプログラムにおいて講じられているか否かを判定する。
このため、本実施の形態によれば、プログラムの解析のみでは抽出できない脅威に対する対策の有無を判定することできる。そして、本実施の形態によれば、判定結果に基づき、プログラムの解析のみでは抽出できない脅威に対する対策を講じることができる。
また、本実施の形態で用いられるソフトウェアトレース情報106はソフトウェア開発の一環で生成されるものであるため、脆弱性分析のために新たなデータを生成する必要はない。したがって、脆弱性分析を行うユーザの手間を増やさずに、より厳密な脆弱性分析を実現することができる。
また、本実施の形態では、実装段階のプログラムから脆弱性分析に必要な変数や関数の情報を取得することができる。このため、本実施の形態によれば、機密性や完全性等の具体的な脆弱性を特定することができる。
従来技術では、セキュリティの3要素と呼ばれる機密性、完全性、可用性に関する脆弱性を特定することができなかった。例えば、データの完全性に関する脆弱性を特定するためには、まず対象となるデータが改ざんが許容されないデータであることを判定し、その上で改ざんを防ぐための対策が講じられているか否かを評価する必要がある。しかし、プログラム(ソースコード)にはデータの完全性に関する情報がないため、完全性に関する脆弱性を特定することができない。
本実施の形態では、図6に示すように、プログラム仕様書に基づくリスク分析により完全性に関する脅威が脅威情報108に記述されている場合は、セキュリティ設計装置100は、プログラム105において完全性に関する脅威への対策が講じられているか否かを評価することができる。更に、プログラム仕様書に基づくリスク分析により機密性に関する脅威(例えば、漏洩)が脅威情報108に記述されている場合は、セキュリティ設計装置100は、プログラム105において機密性に関する脅威への対策が講じられているか否かを評価することができる。また、リスク分析により可用性に関する脅威(例えば、DoS(Denial of Service)攻撃)が脅威情報108に記述されている場合は、セキュリティ設計装置100は、プログラム105において可用性に関する脅威への対策が講じられているか否かを評価することができる。
従来技術では、セキュリティの3要素と呼ばれる機密性、完全性、可用性に関する脆弱性を特定することができなかった。例えば、データの完全性に関する脆弱性を特定するためには、まず対象となるデータが改ざんが許容されないデータであることを判定し、その上で改ざんを防ぐための対策が講じられているか否かを評価する必要がある。しかし、プログラム(ソースコード)にはデータの完全性に関する情報がないため、完全性に関する脆弱性を特定することができない。
本実施の形態では、図6に示すように、プログラム仕様書に基づくリスク分析により完全性に関する脅威が脅威情報108に記述されている場合は、セキュリティ設計装置100は、プログラム105において完全性に関する脅威への対策が講じられているか否かを評価することができる。更に、プログラム仕様書に基づくリスク分析により機密性に関する脅威(例えば、漏洩)が脅威情報108に記述されている場合は、セキュリティ設計装置100は、プログラム105において機密性に関する脅威への対策が講じられているか否かを評価することができる。また、リスク分析により可用性に関する脅威(例えば、DoS(Denial of Service)攻撃)が脅威情報108に記述されている場合は、セキュリティ設計装置100は、プログラム105において可用性に関する脅威への対策が講じられているか否かを評価することができる。
実施の形態2.
以上の実施の形態1は、特定の脆弱性箇所特定方法に依存するものではないが、実施の形態2では、脆弱性箇所特定方法として静的解析の一種であるテイント解析を利用する例を説明する。更に、実施の形態2では、テイント解析の実現方法として型検査を利用する例を説明する。
本実施の形態では、主に実施の形態1との差異を説明する。
なお、以下で説明していない事項は、実施の形態1と同様である。
以上の実施の形態1は、特定の脆弱性箇所特定方法に依存するものではないが、実施の形態2では、脆弱性箇所特定方法として静的解析の一種であるテイント解析を利用する例を説明する。更に、実施の形態2では、テイント解析の実現方法として型検査を利用する例を説明する。
本実施の形態では、主に実施の形態1との差異を説明する。
なお、以下で説明していない事項は、実施の形態1と同様である。
***構成の説明***
図12は、実施の形態2に係るセキュリティ設計装置100の機能構成例を示す。図2と比較して、図12では、型通知部206が追加されている。また、図12では、関数特定情報213と脅威関与変数情報214が型通知部206に入力され、型情報プログラム216が型通知部206から脆弱性判定部204に出力される。なお、型通知部206も脅威情報取得部201等と同様に検証プログラム104により実現されるものとする。
なお、図12では、2つのプログラム105が記載されているが、これは作図上の理由によるものであり、両者は同一である。つまり、型通知部206に入力されるプログラム105と脆弱性特定情報選択部202に入力されるプログラム105は同一である。
図12は、実施の形態2に係るセキュリティ設計装置100の機能構成例を示す。図2と比較して、図12では、型通知部206が追加されている。また、図12では、関数特定情報213と脅威関与変数情報214が型通知部206に入力され、型情報プログラム216が型通知部206から脆弱性判定部204に出力される。なお、型通知部206も脅威情報取得部201等と同様に検証プログラム104により実現されるものとする。
なお、図12では、2つのプログラム105が記載されているが、これは作図上の理由によるものであり、両者は同一である。つまり、型通知部206に入力されるプログラム105と脆弱性特定情報選択部202に入力されるプログラム105は同一である。
セキュリティ設計装置100のハードウェア構成例は図1に示す通りである。
なお、図示は省略するが、本実施の形態では、プロセッサ101のブロックに型通知部206のブロックが追加される。また、本実施の形態では、主記憶装置102のブロックに型情報プログラム216のブロックが追加される。
なお、図示は省略するが、本実施の形態では、プロセッサ101のブロックに型通知部206のブロックが追加される。また、本実施の形態では、主記憶装置102のブロックに型情報プログラム216のブロックが追加される。
型通知部206は、入力処理関数の戻り値の型と出力処理関数の引数の型と対策関数の引数及び戻り値の型を脆弱性判定部204に通知する。具体的には、型通知部206は、入力処理関数の戻り値の型と出力処理関数の引数の型と対策関数の引数及び戻り値の型を示す型情報を型情報プログラム216に含ませる。つまり、型情報プログラム216は、型情報が追加されたプログラム105である。
本実施の形態では、脆弱性判定部204は、型情報プログラム216の型情報で通知される入力処理関数の戻り値の型と出力処理関数の引数の型と対策関数の引数及び戻り値の型に基づき、対策関数が入力処理関数と出力処理関数との間に記述されているか否かを判定する。
本実施の形態では、脆弱性判定部204は、型情報プログラム216の型情報で通知される入力処理関数の戻り値の型と出力処理関数の引数の型と対策関数の引数及び戻り値の型に基づき、対策関数が入力処理関数と出力処理関数との間に記述されているか否かを判定する。
図13は、型通知部206によりプログラム105に追加される型情報217の例を示す。前述したように、型情報217が追加されたプログラム105が型情報プログラム216に相当する。図13の詳細は後述する。
また、本実施の形態では、図14に示すように、対策関数情報107に対策関数の引数及び戻り値の型の情報が含まれている。具体的には、対策関数「verifyInput」の引数の型として「int<insecure>」が記載されており、戻り値の型として「int<secure>」が記載されている。
また、本実施の形態では、図14に示すように、対策関数情報107に対策関数の引数及び戻り値の型の情報が含まれている。具体的には、対策関数「verifyInput」の引数の型として「int<insecure>」が記載されており、戻り値の型として「int<secure>」が記載されている。
***動作の説明***
図15は、本実施の形態に係るセキュリティ設計装置100の動作例を示す。
なお、実施の形態1と同様に、本実施の形態では、図4に示すプログラム105を検証対象とする。また、実施の形態1と同様に、脅威関与変数情報214には脅威関与変数として「cmd」が記載されているものとする。
図15は、本実施の形態に係るセキュリティ設計装置100の動作例を示す。
なお、実施の形態1と同様に、本実施の形態では、図4に示すプログラム105を検証対象とする。また、実施の形態1と同様に、脅威関与変数情報214には脅威関与変数として「cmd」が記載されているものとする。
ステップS701及びステップS702は、実施の形態1に示したものと同じであるため、説明を省略する。
ステップS801において、脆弱性特定情報選択部202は実施の形態1のステップS703と同様の手順にて、対策関数を抽出し、関数特定情報213を出力する。但し、ステップS801では、脆弱性特定情報選択部202は関数特定情報213を型通知部206に出力する。また、関数特定情報213には、図14に示される「引数の型:int<insecure>」と「戻り値の型:int<secure>」が記載されている。
ステップS704は実施の形態1に示したものと同じであるため、説明を省略する。
ステップS802では、型通知部206がプログラム105を解析して入力処理関数と出力処理関数とを抽出する。入力処理関数と出力処理関数の抽出手順は実施の形態1のステップS705の手順と同じである。
つまり、型通知部206は、脅威関与変数情報214に示される脅威関与変数と対応付けられた入力処理関数と出力処理関数を抽出する。
型通知部206が脅威関与変数として「変数cmd」が示される脅威関与変数情報214を取得したとする。この場合に、型通知部206は、図4のプログラム105において「変数cmd」と対応付けられている入力処理関数と出力処理関数を抽出する。具体的には、型通知部206は、図4のプログラム105から、符号402で示される関数「receiveFromHMI」と符号404で示される関数「sendToDevice」(符号403の「cmd」と対応付けられている)を取得する。
つまり、型通知部206は、脅威関与変数情報214に示される脅威関与変数と対応付けられた入力処理関数と出力処理関数を抽出する。
型通知部206が脅威関与変数として「変数cmd」が示される脅威関与変数情報214を取得したとする。この場合に、型通知部206は、図4のプログラム105において「変数cmd」と対応付けられている入力処理関数と出力処理関数を抽出する。具体的には、型通知部206は、図4のプログラム105から、符号402で示される関数「receiveFromHMI」と符号404で示される関数「sendToDevice」(符号403の「cmd」と対応付けられている)を取得する。
ステップS803では、型通知部206は、ステップS802で抽出した入力処理関数の戻り値の型と出力処理関数の引数の型を識別する。また、型通知部206は、識別した入力処理関数の戻り値の型と出力処理関数の引数の型と、関数特定情報213に示される対策関数の引数及び戻り値の型を通知する型情報217を生成する。更に、型通知部206は、生成した型情報217をプログラム105に追加して型情報プログラム216を生成する。
図13は、ステップS802において入力処理関数として「receiveFromHMI」が抽出され、出力処理関数として「sendToDevice」が抽出された場合の型情報217を示す。
型情報217では、各関数の引数又は/及び戻り値の型に加えて、各関数の種類と、各関数とテイント解析との関係も示される。
つまり、入力処理関数「receiveFromHMI」の種類は「入力」である。また、入力処理関数「receiveFromHMI」はテイント解析における「Source」に対応する。
また、出力処理関数「sendToDevice」の種類は「使用」である。また、出力処理関数「sendToDevice」はテイント解析におけるSinkに対応する。
また、対策関数「verifyInput」の種類は「入力検証」である。また、対策関数「verifyInput」はテイント解析における「Sanitizer」に対応する。
また、図13の型情報217では、入力処理関数「receiveFromHMI」の戻り値の型が「int<insecure>」であることが示される。また、図13の型情報217では、出力処理関数「sendToDevice」の引数の型が「int<secure>」であることが示される。更に、図13の型情報217では、対策関数「verifyInput」の引数の型が「int<insecure>」であり、戻り値の型が「int<secure>」であることが示される。
型情報217では、各関数の引数又は/及び戻り値の型に加えて、各関数の種類と、各関数とテイント解析との関係も示される。
つまり、入力処理関数「receiveFromHMI」の種類は「入力」である。また、入力処理関数「receiveFromHMI」はテイント解析における「Source」に対応する。
また、出力処理関数「sendToDevice」の種類は「使用」である。また、出力処理関数「sendToDevice」はテイント解析におけるSinkに対応する。
また、対策関数「verifyInput」の種類は「入力検証」である。また、対策関数「verifyInput」はテイント解析における「Sanitizer」に対応する。
また、図13の型情報217では、入力処理関数「receiveFromHMI」の戻り値の型が「int<insecure>」であることが示される。また、図13の型情報217では、出力処理関数「sendToDevice」の引数の型が「int<secure>」であることが示される。更に、図13の型情報217では、対策関数「verifyInput」の引数の型が「int<insecure>」であり、戻り値の型が「int<secure>」であることが示される。
入力処理関数「receiveFromHMI」はネットワークから入力されたデータを返す関数である。このため、入力処理関数「receiveFromHMI」の戻り値は、テイント解析では汚染されたデータ(テイント)と見なされる。従って、型通知部206は、入力処理関数「receiveFromHMI」の戻り値の型を「int<insecure>」と識別する。
出力処理関数「sendToDevice」は、汚染されていないデータを引数として受け取る関数である。このため、型通知部206は、出力処理関数「sendToDevice」の引数の型を「int<secure>」と識別する。
なお、図13の型情報217に示される対策関数「verifyInput」の引数の型である「int<insecure>」と、戻り値の型である「int<secure>」は、図14の対策関数情報107に示す型の情報である。対策関数「verifyInput」は、汚染されたデータを引数として受け取り、検証し、汚染が除去されたデータを返す関数である。対策関数「verifyInput」の引数の型は「int<insecure>」であり、戻り値の型は「int<secure>」である。
なお、本実施の形態でも、図14の対策関数情報107の代わりに図8の対策関数情報107を用い、型通知部206が対策関数「verifyInput」の引数の型及び戻り値の型を識別するようにしてもよい。
出力処理関数「sendToDevice」は、汚染されていないデータを引数として受け取る関数である。このため、型通知部206は、出力処理関数「sendToDevice」の引数の型を「int<secure>」と識別する。
なお、図13の型情報217に示される対策関数「verifyInput」の引数の型である「int<insecure>」と、戻り値の型である「int<secure>」は、図14の対策関数情報107に示す型の情報である。対策関数「verifyInput」は、汚染されたデータを引数として受け取り、検証し、汚染が除去されたデータを返す関数である。対策関数「verifyInput」の引数の型は「int<insecure>」であり、戻り値の型は「int<secure>」である。
なお、本実施の形態でも、図14の対策関数情報107の代わりに図8の対策関数情報107を用い、型通知部206が対策関数「verifyInput」の引数の型及び戻り値の型を識別するようにしてもよい。
次に、ステップS804において、脆弱性判定部204は型情報プログラム216を取得し、型情報プログラム216の型情報217を用いて型検査を行い、プログラム105に対策処理が講じられているか否かを判定する。
型検査でエラーが発生した場合は、脆弱性判定部204は、エラー発生箇所を脆弱性として特定する一方、型検査でエラーが発生しなかった場合はプログラム105に脆弱性がないと判定する。
型検査でエラーが発生した場合は、脆弱性判定部204は、エラー発生箇所を脆弱性として特定する一方、型検査でエラーが発生しなかった場合はプログラム105に脆弱性がないと判定する。
図16は、図4に示すプログラム105の疑似コード1002を示す。図17は、図9に示すプログラム901の疑似コード1005を示す。
疑似コード1002及び疑似コード1005を用いて、脆弱性判定部204による型検査の動作を説明する。
疑似コード1002及び疑似コード1005を用いて、脆弱性判定部204による型検査の動作を説明する。
疑似コード1002の場合、コード記述1003で変数「cmd」に、関数「receiveFromHMI」の戻り値として「int<insecure>」型の値が代入される。
次に、コード記述1004で変数「cmd」が、関数「sendToDevice」の引数として渡される。
しかし、関数「sendToDevice」は引数として「int<secure>」型の値を受け取ることになっている。このため、変数cmdの型と関数「sendToDevice」の引数の型とが一致せず、型のエラーが発生する。
以上により、脆弱性判定部204は、疑似コード1002のコード記述1004に脆弱性があると判定する。
次に、コード記述1004で変数「cmd」が、関数「sendToDevice」の引数として渡される。
しかし、関数「sendToDevice」は引数として「int<secure>」型の値を受け取ることになっている。このため、変数cmdの型と関数「sendToDevice」の引数の型とが一致せず、型のエラーが発生する。
以上により、脆弱性判定部204は、疑似コード1002のコード記述1004に脆弱性があると判定する。
一方、疑似コード1005の場合、コード記述1006で変数「cmd」に、関数「receiveFromHMI」の戻り値として「int<insecure>」型の値が代入される。
次に、コード記述1007で変数「cmd」が、引数として関数「verifyInput」に渡される。
関数「verifyInput」は引数として「int<insecure>」型の値を受け取ることになっている。このため、変数「cmd」の型と関数「verifyInput」の引数の型とが一致しており、コード記述1007では型のエラーは発生しない。
そして、関数「verifyInput」の戻り値として「int<secure>」型の値が変数「cmd」に代入される。
次に、コード記述1008で変数「cmd」が、引数として関数「sendToDevice」に渡される。関数「sendToDevice」は引数として「int<secure>」型の値を受け取ることになっている。このため、変数「cmd」の型と関数「sendToDevice」の引数の型とが一致しており、コード記述1008では型のエラーは発生しない。
以上により、脆弱性判定部204は、疑似コード1005には脆弱性がないと判定する。
次に、コード記述1007で変数「cmd」が、引数として関数「verifyInput」に渡される。
関数「verifyInput」は引数として「int<insecure>」型の値を受け取ることになっている。このため、変数「cmd」の型と関数「verifyInput」の引数の型とが一致しており、コード記述1007では型のエラーは発生しない。
そして、関数「verifyInput」の戻り値として「int<secure>」型の値が変数「cmd」に代入される。
次に、コード記述1008で変数「cmd」が、引数として関数「sendToDevice」に渡される。関数「sendToDevice」は引数として「int<secure>」型の値を受け取ることになっている。このため、変数「cmd」の型と関数「sendToDevice」の引数の型とが一致しており、コード記述1008では型のエラーは発生しない。
以上により、脆弱性判定部204は、疑似コード1005には脆弱性がないと判定する。
このように、本実施の形態では、脆弱性判定部204は、入力処理関数の戻り値の型と出力処理関数の引数の型と対策関数の引数及び戻り値の型との整合性を解析して、対策関数がプログラム内の適切な位置、すなわち、入力処理関数と出力処理関数との間に記述されているか否かを判定する。
***実施の形態の効果の説明***
以上のように、本実施の形態では、型検査により対策関数がプログラムに記述されているか否かを判定する。このため、本実施の形態によれば、少ない計算負荷で脅威への対策の有無を判定することができる。
また、本実施の形態では、型情報がプログラムに付加される。このため、型検査を効率的に行うことができる。
以上のように、本実施の形態では、型検査により対策関数がプログラムに記述されているか否かを判定する。このため、本実施の形態によれば、少ない計算負荷で脅威への対策の有無を判定することができる。
また、本実施の形態では、型情報がプログラムに付加される。このため、型検査を効率的に行うことができる。
実施の形態3.
以上の実施の形態1及び実施の形態2は、特定の開発プロセスを想定したものではなかった。
本実施の形態では、モデルベース開発あるいはモデル駆動開発等のモデルを利用したソフトウェア開発で得られたプログラムにおいて脅威への対策が講じられているか否かを判定する例を説明する。
本実施の形態では、主に実施の形態1との差異を説明する。
なお、以下で説明していない事項は、実施の形態1と同様である。
以上の実施の形態1及び実施の形態2は、特定の開発プロセスを想定したものではなかった。
本実施の形態では、モデルベース開発あるいはモデル駆動開発等のモデルを利用したソフトウェア開発で得られたプログラムにおいて脅威への対策が講じられているか否かを判定する例を説明する。
本実施の形態では、主に実施の形態1との差異を説明する。
なお、以下で説明していない事項は、実施の形態1と同様である。
以下では、モデルを利用したソフトウェア開発プロセスを総称してモデルベース開発と呼ぶこととする。
モデルベース開発では、自然言語で仕様書を記述する代わりに、コンピュータによる処理に適した形式で仕様を生成する。これをモデル化と呼び、生成される仕様をモデルと呼ぶ。モデルは厳密な形式に従って生成されるため、解釈の曖昧さを排除することができる。また、モデルをシミュレーションとして動作させることが可能である。また、モデルからソースコードを自動生成することが可能な場合もある。更に、このモデルとソースコードとの関係に見られるように、各データ同士が対応付けられており、実施の形態1で説明したソフトウェアトレース情報の入手が容易である。
モデルベース開発では、自然言語で仕様書を記述する代わりに、コンピュータによる処理に適した形式で仕様を生成する。これをモデル化と呼び、生成される仕様をモデルと呼ぶ。モデルは厳密な形式に従って生成されるため、解釈の曖昧さを排除することができる。また、モデルをシミュレーションとして動作させることが可能である。また、モデルからソースコードを自動生成することが可能な場合もある。更に、このモデルとソースコードとの関係に見られるように、各データ同士が対応付けられており、実施の形態1で説明したソフトウェアトレース情報の入手が容易である。
図18は、モデルベース開発の簡単な流れを表す。
先ず、モデル化1101が行われ、モデル1102が生成される。その後、検証1103により、モデル1102を利用して要件の検証又は設計の改善が進められる。
検証1103では、上述の通りシミュレーションを利用して、例えばプログラム1105の動作をあらかじめ検証することもできる。また、形式手法と呼ばれる手法により、モデル1102が要件を満たすことを数学的に証明することもできる。モデル1102が完成した後、コード生成1104によってプログラム1105(ソースコード)が生成される。また、モデル1102とプログラム1105との対応関係を表す情報が、トレース情報1106として存在する。
先ず、モデル化1101が行われ、モデル1102が生成される。その後、検証1103により、モデル1102を利用して要件の検証又は設計の改善が進められる。
検証1103では、上述の通りシミュレーションを利用して、例えばプログラム1105の動作をあらかじめ検証することもできる。また、形式手法と呼ばれる手法により、モデル1102が要件を満たすことを数学的に証明することもできる。モデル1102が完成した後、コード生成1104によってプログラム1105(ソースコード)が生成される。また、モデル1102とプログラム1105との対応関係を表す情報が、トレース情報1106として存在する。
図19は、モデルベース開発に実施の形態1又は実施の形態2に係るセキュリティ設計装置100を適用した流れを示している。
モデルベース開発における検証1203の一環としてリスク分析が行われ、脅威一覧1208が出力される。また、脆弱性判定1207によってプログラム1205(ソースコード)に対する脆弱性の有無が判定される。
通常、脆弱性判定1207はプログラム1205のみを用いて行われるが、本実施の形態ではトレース情報1206と脅威一覧1208も利用する。トレース情報1206は、実施の形態1のソフトウェアトレース情報106に対応する。脅威一覧1208は、実施の形態1の脅威情報108に対応する。
なお、図19において、モデル化1201はモデル化1101と同じである。また、モデル1202もモデル1102と同じである。更に、コード生成1204はコード生成1104と同じである。
モデルベース開発における検証1203の一環としてリスク分析が行われ、脅威一覧1208が出力される。また、脆弱性判定1207によってプログラム1205(ソースコード)に対する脆弱性の有無が判定される。
通常、脆弱性判定1207はプログラム1205のみを用いて行われるが、本実施の形態ではトレース情報1206と脅威一覧1208も利用する。トレース情報1206は、実施の形態1のソフトウェアトレース情報106に対応する。脅威一覧1208は、実施の形態1の脅威情報108に対応する。
なお、図19において、モデル化1201はモデル化1101と同じである。また、モデル1202もモデル1102と同じである。更に、コード生成1204はコード生成1104と同じである。
以上のように、モデルベース開発の枠組を利用すればトレース情報の入手がより容易になり、脆弱性分析を行うユーザの手間を増やさずに、分析を詳細化できる効果がより高くなる。
以上、本発明の実施の形態について説明したが、これらの実施の形態のうち、2つ以上を組み合わせて実施しても構わない。
あるいは、これらの実施の形態のうち、1つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、2つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
あるいは、これらの実施の形態のうち、1つを部分的に実施しても構わない。
あるいは、これらの実施の形態のうち、2つ以上を部分的に組み合わせて実施しても構わない。
なお、本発明は、これらの実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。
***ハードウェア構成の説明***
最後に、セキュリティ設計装置100のハードウェア構成の補足説明を行う。
図1に示すプロセッサ101は、プロセッシングを行うIC(Integrated Circuit)である。
プロセッサ101は、CPU(Central Processing Unit)、DSP(Digital Signal Processor)等である。
図1に示す主記憶装置102は、RAM(Random Access Memory)である。
図1に示す補助記憶装置103は、ROM(Read Only Memory)、フラッシュメモリ、HDD(Hard Disk Drive)等である。
最後に、セキュリティ設計装置100のハードウェア構成の補足説明を行う。
図1に示すプロセッサ101は、プロセッシングを行うIC(Integrated Circuit)である。
プロセッサ101は、CPU(Central Processing Unit)、DSP(Digital Signal Processor)等である。
図1に示す主記憶装置102は、RAM(Random Access Memory)である。
図1に示す補助記憶装置103は、ROM(Read Only Memory)、フラッシュメモリ、HDD(Hard Disk Drive)等である。
また、補助記憶装置103には、OS(Operating System)も記憶されている。
そして、OSの少なくとも一部がプロセッサ101により実行される。
プロセッサ101はOSの少なくとも一部を実行しながら、検証プログラム104を実行する。
プロセッサ101がOSを実行することで、タスク管理、メモリ管理、ファイル管理、通信制御等が行われる。
また、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204、脆弱性情報生成部205及び型通知部206の処理の結果を示す情報、データ、信号値及び変数値の少なくともいずれかが、主記憶装置102、補助記憶装置103、プロセッサ101内のレジスタ及びキャッシュメモリの少なくともいずれかに記憶される。
また、検証プログラム104は、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ(登録商標)ディスク、DVD等の可搬記録媒体に格納されていてもよい。そして、検証プログラム104が格納された可搬記録媒体を商業的に流通させてもよい。
そして、OSの少なくとも一部がプロセッサ101により実行される。
プロセッサ101はOSの少なくとも一部を実行しながら、検証プログラム104を実行する。
プロセッサ101がOSを実行することで、タスク管理、メモリ管理、ファイル管理、通信制御等が行われる。
また、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204、脆弱性情報生成部205及び型通知部206の処理の結果を示す情報、データ、信号値及び変数値の少なくともいずれかが、主記憶装置102、補助記憶装置103、プロセッサ101内のレジスタ及びキャッシュメモリの少なくともいずれかに記憶される。
また、検証プログラム104は、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ(登録商標)ディスク、DVD等の可搬記録媒体に格納されていてもよい。そして、検証プログラム104が格納された可搬記録媒体を商業的に流通させてもよい。
また、脅威情報取得部201、脆弱性特定情報選択部202、脅威関与変数抽出部203、脆弱性判定部204、脆弱性情報生成部205及び型通知部206の「部」を、「回路」又は「工程」又は「手順」又は「処理」に読み替えてもよい。
また、セキュリティ設計装置100は、処理回路により実現されてもよい。処理回路は、例えば、ロジックIC(Integrated Circuit)、GA(Gate Array)、ASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)である。
なお、本明細書では、プロセッサと処理回路との上位概念を、「プロセッシングサーキットリー」という。
つまり、プロセッサと処理回路とは、それぞれ「プロセッシングサーキットリー」の具体例である。
また、セキュリティ設計装置100は、処理回路により実現されてもよい。処理回路は、例えば、ロジックIC(Integrated Circuit)、GA(Gate Array)、ASIC(Application Specific Integrated Circuit)、FPGA(Field-Programmable Gate Array)である。
なお、本明細書では、プロセッサと処理回路との上位概念を、「プロセッシングサーキットリー」という。
つまり、プロセッサと処理回路とは、それぞれ「プロセッシングサーキットリー」の具体例である。
100 セキュリティ設計装置、101 プロセッサ、102 主記憶装置、103 補助記憶装置、104 検証プログラム、105 プログラム、106 ソフトウェアトレース情報、107 対策関数情報、108 脅威情報、109 脆弱性情報、110 脆弱性DB、111 入力インターフェース、112 表示インターフェース、113 ネットワークインターフェース、114 データバス、115 脆弱性対策処理情報、201 脅威情報取得部、202 脆弱性特定情報選択部、203 脅威関与変数抽出部、204 脆弱性判定部、205 脆弱性情報生成部、206 型通知部、211 脆弱性識別子、212 脅威関与要素情報、213 関数特定情報、214 脅威関与変数情報、215 判定結果、216 型情報プログラム、217 型情報、250 判定部、300 システム構成図、301 HMI、302 機器コントローラ、303 通信S/W、304 フィールド機器、305 伝送路、306 伝送路、308 制御コマンド、309 制御信号、310 プログラム仕様図、311 状態遷移、312 状態、313 状態、314 状態遷移、315 状態遷移、901 プログラム、1002 疑似コード、1003 コード記述、1004 コード記述、1005 疑似コード、1006 コード記述、1007 コード記述、1008 コード記述、1101 モデル化、1102 モデル、1103 検証、1104 コード生成、1105 プログラム、1106 トレース情報、1201 モデル化、1202 モデル、1203 検証、1204 コード生成、1205 プログラム、1206 トレース情報、1207 脆弱性判定、1208 脅威一覧。
Claims (10)
- プログラムの仕様が示されるプログラム仕様書に基づくリスク分析により特定された前記プログラムの実行時に発生し得る脅威と、前記プログラム仕様書に示される要素のうち前記脅威の発生に関与する要素である脅威関与要素とが示される脅威情報を取得する脅威情報取得部と、
前記プログラムに記述される変数のうち前記脅威関与要素に対応する変数を脅威関与変数として抽出し、抽出した前記脅威関与変数に基づき前記プログラムを解析して前記脅威への対策が前記プログラムにおいて講じられているか否かを判定する判定部とを有する情報処理装置。 - 前記判定部は、
前記脅威への対策を実現する処理である対策処理が前記プログラムに含まれているか否かを解析して、前記脅威への対策が前記プログラムにおいて講じられているか否かを判定する請求項1に記載の情報処理装置。 - 前記判定部は、
前記対策処理を実現する関数である対策関数が、前記脅威関与変数と対応付けられて前記プログラムに記述されている場合に、前記対策処理が前記プログラムに含まれると判定する請求項2に記載の情報処理装置。 - 前記判定部は、
前記対策関数が、前記脅威関与変数と対応付けられた入力処理関数と前記脅威関与変数と対応付けられた出力処理関数との間に記述されている場合に、前記対策処理が前記プログラムに含まれると判定する請求項3に記載の情報処理装置。 - 前記判定部は、
相互に関連する前記プログラムの要素と前記プログラム仕様書の要素とが対応付けられて示されるソフトウェアトレース情報を参照し、前記ソフトウェアトレース情報において前記脅威関与要素と対応付けられている変数を前記脅威関与変数として抽出する請求項1に記載の情報処理装置。 - 前記判定部は、
前記入力処理関数の戻り値の型と前記出力処理関数の引数の型と前記対策関数の引数及び戻り値の型に基づき、前記対策関数が前記入力処理関数と前記出力処理関数との間に記述されているか否かを判定する請求項4に記載の情報処理装置。 - 前記情報処理装置は、更に、
前記入力処理関数の戻り値の型と前記出力処理関数の引数の型と前記対策関数の引数及び戻り値の型を前記判定部に通知する型通知部を有し、
前記判定部は、
前記型通知部から通知された前記入力処理関数の戻り値の型と前記出力処理関数の引数の型と前記対策関数の引数及び戻り値の型とに基づき、前記対策関数が前記入力処理関数と前記出力処理関数との間に記述されているか否かを判定する請求項6に記載の情報処理装置。 - 前記判定部は、
モデルを利用したソフトウェア開発により得られたプログラムにおいて前記脅威への対策が講じられているか否かを判定する請求項1に記載の情報処理装置。 - コンピュータが、プログラムの仕様が示されるプログラム仕様書に基づくリスク分析により特定された前記プログラムの実行時に発生し得る脅威と、前記プログラム仕様書に示される要素のうち前記脅威の発生に関与する要素である脅威関与要素とが示される脅威情報を取得し、
前記コンピュータが、前記プログラムに記述される変数のうち前記脅威関与要素に対応する変数を脅威関与変数として抽出し、抽出した前記脅威関与変数に基づき前記プログラムを解析して前記脅威への対策が前記プログラムにおいて講じられているか否かを判定する情報処理方法。 - プログラムの仕様が示されるプログラム仕様書に基づくリスク分析により特定された前記プログラムの実行時に発生し得る脅威と、前記プログラム仕様書に示される要素のうち前記脅威の発生に関与する要素である脅威関与要素とが示される脅威情報を取得する脅威情報取得処理と、
前記プログラムに記述される変数のうち前記脅威関与要素に対応する変数を脅威関与変数として抽出し、抽出した前記脅威関与変数に基づき前記プログラムを解析して前記脅威への対策が前記プログラムにおいて講じられているか否かを判定する判定処理とをコンピュータに実行させる情報処理プログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021528741A JP7008879B2 (ja) | 2019-06-26 | 2019-06-26 | 情報処理装置、情報処理方法及び情報処理プログラム |
PCT/JP2019/025382 WO2020261430A1 (ja) | 2019-06-26 | 2019-06-26 | 情報処理装置、情報処理方法及び情報処理プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2019/025382 WO2020261430A1 (ja) | 2019-06-26 | 2019-06-26 | 情報処理装置、情報処理方法及び情報処理プログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2020261430A1 true WO2020261430A1 (ja) | 2020-12-30 |
Family
ID=74060827
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2019/025382 WO2020261430A1 (ja) | 2019-06-26 | 2019-06-26 | 情報処理装置、情報処理方法及び情報処理プログラム |
Country Status (2)
Country | Link |
---|---|
JP (1) | JP7008879B2 (ja) |
WO (1) | WO2020261430A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112926058A (zh) * | 2021-03-25 | 2021-06-08 | 支付宝(杭州)信息技术有限公司 | 代码处理方法、污点分析方法和装置 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2006087780A1 (ja) * | 2005-02-17 | 2006-08-24 | Fujitsu Limited | 脆弱性監査プログラム、脆弱性監査装置、脆弱性監査方法 |
JP2006523898A (ja) * | 2003-04-18 | 2006-10-19 | オンス ラブス,インク | ソースコードの脆弱点の検出法および検出システム |
JP2007052625A (ja) * | 2005-08-18 | 2007-03-01 | Hitachi Software Eng Co Ltd | ソースコード脆弱性検査装置 |
JP2017068825A (ja) * | 2015-09-29 | 2017-04-06 | パナソニックIpマネジメント株式会社 | ソフトウェア開発システムおよびプログラム |
-
2019
- 2019-06-26 JP JP2021528741A patent/JP7008879B2/ja active Active
- 2019-06-26 WO PCT/JP2019/025382 patent/WO2020261430A1/ja active Application Filing
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006523898A (ja) * | 2003-04-18 | 2006-10-19 | オンス ラブス,インク | ソースコードの脆弱点の検出法および検出システム |
WO2006087780A1 (ja) * | 2005-02-17 | 2006-08-24 | Fujitsu Limited | 脆弱性監査プログラム、脆弱性監査装置、脆弱性監査方法 |
JP2007052625A (ja) * | 2005-08-18 | 2007-03-01 | Hitachi Software Eng Co Ltd | ソースコード脆弱性検査装置 |
JP2017068825A (ja) * | 2015-09-29 | 2017-04-06 | パナソニックIpマネジメント株式会社 | ソフトウェア開発システムおよびプログラム |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112926058A (zh) * | 2021-03-25 | 2021-06-08 | 支付宝(杭州)信息技术有限公司 | 代码处理方法、污点分析方法和装置 |
Also Published As
Publication number | Publication date |
---|---|
JP7008879B2 (ja) | 2022-01-25 |
JPWO2020261430A1 (ja) | 2021-10-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7788730B2 (en) | Secure bytecode instrumentation facility | |
JP4976991B2 (ja) | 情報処理装置、プログラム検証方法及びプログラム | |
JPWO2006087780A1 (ja) | 脆弱性監査プログラム、脆弱性監査装置、脆弱性監査方法 | |
US11748487B2 (en) | Detecting a potential security leak by a microservice | |
Chowdhury et al. | Safe and secure automotive over-the-air updates | |
US20090113552A1 (en) | System and Method To Analyze Software Systems Against Tampering | |
CN108182359B (zh) | 一种测试可信环境下api安全性的方法、装置及存储介质 | |
CN110555290A (zh) | 一种基于fpga的工控软件版权保护方法及系统 | |
CN116361807A (zh) | 风险管控方法、装置、存储介质及电子设备 | |
JP5077455B2 (ja) | 脆弱性監査プログラム、脆弱性監査装置、脆弱性監査方法 | |
US8176560B2 (en) | Evaluation of tamper resistant software system implementations | |
US8875297B2 (en) | Interactive analysis of a security specification | |
JP7008879B2 (ja) | 情報処理装置、情報処理方法及び情報処理プログラム | |
JP6632777B2 (ja) | セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム | |
JP2009129204A (ja) | コード検査システム及びコード検査方法及びプログラム | |
JP2020505708A (ja) | ソフトウェアコードをセキュアにするための方法 | |
Zhioua et al. | Formal specification and verification of security guidelines | |
JP6608569B1 (ja) | セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム | |
Zhioua et al. | Framework for the formal specification and verification of security guidelines | |
Goli et al. | VIP-VP: Early validation of SoCs information flow policies using SystemC-based virtual prototypes | |
Lloyd et al. | Security analysis of a biometric authentication system using UMLsec and JML | |
JP6494887B1 (ja) | 検査装置、検査方法及び検査プログラム | |
Ghorbanzadeh et al. | Detecting application logic vulnerabilities via finding incompatibility between application design and implementation | |
JP2010244139A (ja) | 対策網羅性検査装置 | |
KR102016967B1 (ko) | 시스템 정보 데이터 상관/연관 분석을 통한 시스템 취약성/위험 측정 및 처리 방법 및 그를 위한 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 19934496 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2021528741 Country of ref document: JP Kind code of ref document: A |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 19934496 Country of ref document: EP Kind code of ref document: A1 |