JP6584737B1 - Threat identification device, threat identification method, and threat identification program - Google Patents

Abstract

The occurrence location specifying unit (22) is based on the outline design model (31) indicating the interaction between the components constituting the system, and the threat information (32) indicating the components that may cause a threat. Identify interactions that can cause threats in the components that make up the system. The detail specifying unit (23) realizes the interaction specified by the occurrence location specifying unit (22) based on the detailed design model (33 to 35) indicating processing for realizing the interaction indicated by the outline design model (31). Specify the process to be performed.

Description

  The present invention relates to a technique for identifying a process that may cause a threat in a system.

In the software system development process, the configuration and operation for realizing software functions are gradually refined. The same is true for security-related processes. In the upstream phase of the development phase where abstract design such as system requirements analysis is performed, threats that adversely affect the development target system by performing analysis such as threat analysis and risk analysis. Wash out. Then, in the downstream process of the development phase in which detailed design is performed, when the configuration and operation of the system are materialized, it is analyzed whether there is a vulnerability used for an attack that leads to the identified threat. At this time, a design change such as addition of a security function is performed in order to prevent vulnerability as necessary.
In such an effort, in order to confirm detailed design information and analyze whether a threat can actually occur, knowledge about the attack method that leads to the threat and the vulnerability used in the attack method is required. Furthermore, it is necessary to grasp the detailed mechanism in the system to be developed. Therefore, there is a problem that the work load is high.

  Patent Document 1 describes a design support technology for facilitating the detailed specification of security requirements depending on components (in the literature, “architecture”) for realizing the functions of the system. In this technique, type information of a component that realizes a function and threat information generated for a protected asset are input. Then, using the list of combinations of type information and attack methods prepared in advance and the list of combinations of threats and attack methods, the attack method related to the type of the input component and the input threat Extract attack methods related to information. Next, when the extracted attack methods match each other, the input threat information is output, and when they do not match, they are not output. This facilitates determination of whether or not the identified threat information is generated in the upstream process of the development phase.

JP 2013-152577 A

The technique described in Patent Document 1 narrows down threats that can be generated by specifying an attack method according to the type of component that realizes a function. For this reason, it is impossible to specify in which processing of the detailed system a threat may occur.
An object of the present invention is to make it possible to specify which process indicated by detailed design information can cause a threat.

A threat identification device according to the present invention includes:
Based on the outline design model indicating the interaction between the components constituting the system and the threat information indicating the component that may cause the threat, there is a possibility that the threat is generated in the component constituting the system. An occurrence location identifying part that identifies an interaction;
A detail specifying unit for specifying a process for realizing the interaction specified by the occurrence location specifying unit based on a detailed design model indicating a process for realizing the interaction indicated by the general design model.

  In the present invention, an interaction that may cause a threat is specified in the interaction indicated by the outline design model, and a process corresponding to the specified interaction is specified in the detailed design model. As a result, it is possible to identify a process that may cause a threat.

1 is a configuration diagram of a threat identification device 10 according to Embodiment 1. FIG. 3 is a flowchart showing the operation of the threat identification device 10 according to the first embodiment. FIG. 3 is a diagram illustrating an example of a schematic design model 31 according to the first embodiment. The figure which shows the example of the threat information 32 which concerns on Embodiment 1. FIG. FIG. 3 is a diagram illustrating an example of a detailed design model 33 according to the first embodiment. FIG. 3 is a diagram illustrating an example of a detailed design model 34 according to the first embodiment. FIG. 3 is a diagram illustrating an example of a detailed design model 35 according to the first embodiment. FIG. 3 is a diagram illustrating an example of a detailed design model 35 according to the first embodiment. FIG. 3 is a diagram illustrating an example of a detailed design model 35 according to the first embodiment. FIG. 3 is a diagram illustrating an example of a detailed design model 35 according to the first embodiment. FIG. 4 is a diagram illustrating an example of an inspection rule according to the first embodiment. The block diagram of the threat specific apparatus 10 which concerns on the modification 2. FIG.

Embodiment 1 FIG.
*** Explanation of configuration ***
With reference to FIG. 1, the structure of the threat identification apparatus 10 which concerns on Embodiment 1 is demonstrated.
The threat identification device 10 is a computer.
The threat identification device 10 includes hardware including a processor 11, a memory 12, a storage 13, and a communication interface 14. The processor 11 is connected to other hardware via a signal line, and controls these other hardware.

  The processor 11 is an IC (Integrated Circuit) that performs processing. The processor 11 is a CPU (Central Processing Unit), a DSP (Digital Signal Processor), or a GPU (Graphics Processing Unit) as specific examples.

  The memory 12 is a storage device that temporarily stores data. As a specific example, the memory 12 is an SRAM (Static Random Access Memory) or a DRAM (Dynamic Random Access Memory).

  The storage 13 is a storage device that stores data. The storage 13 is an HDD (Hard Disk Drive) as a specific example. The storage 13 is an SD (registered trademark, Secure Digital) memory card, CF (CompactFlash, registered trademark), NAND flash, flexible disk, optical disk, compact disk, Blu-ray (registered trademark) disk, DVD (Digital Versatile Disk), or the like. It may be a portable recording medium.

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

The threat identification device 10 includes a reception unit 21, an occurrence location identification unit 22, a detailed identification unit 23, and an establishment determination unit 24 as functional components. The function of each functional component of the threat identification device 10 is realized by software.
The storage 13 stores a program that realizes the function of each functional component of the threat identification device 10. This program is read into the memory 12 by the processor 11 and executed by the processor 11. Thereby, the function of each functional component of the threat identification device 10 is realized.

  In FIG. 1, only one processor 11 is shown. However, a plurality of processors 11 may be provided, and a plurality of processors 11 may execute programs that realize each function in cooperation with each other.

*** Explanation of operation ***
The operation of the threat identification device 10 according to the first exemplary embodiment will be described with reference to FIGS.
The operation of the threat identification device 10 according to the first embodiment corresponds to the threat identification method according to the first embodiment. The operation of the threat identification device 10 according to the first embodiment corresponds to the processing of the threat identification program according to the first embodiment.

(Step S1: reception process in FIG. 2)
The accepting unit 21 accepts inputs of the outline design model 31, threat information 32, and detailed design models 33 to 35.
Specifically, the input device connected via the communication interface 14 is operated by the user, and the outline design model 31, the threat information 32, and the detailed design models 33 to 35 are input. The accepting unit 21 accepts the input outline design model 31, threat information 32, and detailed design models 33 to 35 via the communication interface 14. The receiving unit 21 writes the outline design model 31, the threat information 32, and the detailed design models 33 to 35 in the memory 12.

The general design model 31 will be described with reference to FIG.
The outline design model 31 is information representing an abstract specification of a system including a program to be developed. The outline design model 31 shows a plurality of components constituting the system, a connection relationship between the components, and an interaction between components in each function provided by the system.
As a specific example, as shown in FIG. 3, the outline design model 31 includes information on interaction such as message exchange between system components as in a UML (Unified Modeling Language) sequence diagram. In FIG. 3, a connection line representing an interaction is a directed line representing an interaction such as communication data exchanged between each component and a program call. In FIG. 3, an arrow is used as a connection line, and the direction of the arrow represents a procedure or a data flow.

The threat information 32 will be described with reference to FIG.
The threat information 32 indicates, for each threat that can occur in the system represented by the overview design model 31, the components and factors that may cause the threat.
As a specific example, as shown in FIG. 4, the threat information 32 is data represented in a tabular format. The threat information 32 includes a threat description, information assets, and threat factors. The threat description is an explanation of what threats are adversely affecting the system. Information assets are data related to the occurrence of a threat. The threat factor indicates what happens to the information asset and the threat.

The detailed design models 33 to 35 will be described with reference to FIGS.
The detailed design models 33 to 35 are information representing specific specifications of a program to be developed included in the outline design model 31. The detailed design models 33 to 35 indicate a process for realizing the interaction indicated by the outline design model and a definition of data used in the process. The detailed design models 33 to 35 are three types of information having different properties.
Specific examples are as shown in FIGS.

  As shown in FIG. 5, the detailed design model 33 includes interaction information such as message exchange between system components as in a UML sequence diagram. This sequence diagram corresponds to the sequence diagram of the outline design model 31, and shows the names of the internal processes of software performed by exchanging messages and the data flowing as messages. Software internal processing and data definition are included in different detailed design models 34 and 35.

As shown in FIG. 6, the detailed design model 34 includes information described in a UML class diagram. Similarly, as shown in FIGS. 7 to 10, the detailed design model 35 includes information described in a UML class diagram. The detailed design models 34 and 35 show the structure of data used in the sequence diagram message and the internal processing of the software.
In the detailed design models 34 and 35, for example, the data element type included in the message is specified as the data structure. Note that types related to security are defined in advance, and the model is designed to include that type. For example, in the detailed design model 34, a data element is defined as a member of a UserAuthRequest message, and Password is specified as a data type of the password member. The Password type refers to the predefined PASWORD type.
In the process to be described later, the establishment determination unit 24 refers to this information to specify that the password member of UserAuthRequest is used as a password for performing user authentication. In addition, the establishment determination unit 24 also specifies that the minimum length is 8 characters based on the definition of the Password type.

  The outline design model 31 and the detailed design models 33 to 35 are described in a data format capable of expressing a hierarchical structure. For example, the outline design model 31 and the detailed design models 33 to 35 are described in a data format such as XML (Extensible Markup Language) and JSON (Java Script Object Notation).

(Step S2 in FIG. 2: occurrence location specifying process)
The occurrence location identifying unit 22 identifies an interaction that may cause a threat in the components constituting the system, based on the general design model 31 and the threat information 32 received in step S1. The interaction is a set of a message connecting objects in the sequence diagram shown in FIG. 5 and a transmission / reception object existing at both ends of the message.

Specifically, the occurrence location specifying unit 22 reads the outline design model 31 and the threat information 32 from the memory 12. The occurrence location specifying unit 22 specifies an interaction that may cause a threat by specifying an interaction using the information asset indicated by the threat information 32 among the interactions indicated by the outline design model 31. For example, the occurrence location specifying unit 22 specifies the interaction using the Stop command, which is the information asset indicated by the threat information 32 in FIG. 4, from the outline design model 31 shown in FIG. Then, an interaction in which a message is transmitted second from the HMI (an interaction in which a Stop command is transmitted) is specified.
Further, the occurrence location identifying unit 22 identifies an interaction that may cause a threat by identifying an interaction corresponding to a threat factor indicated by the threat information 32 among the interactions indicated by the outline design model 31. Identify. For example, the occurrence location specifying unit 22 specifies an interaction corresponding to an unapproved transmission message that is a cause of the threat indicated by the threat information 32 in FIG. 4 from the general design model 31 shown in FIG. Then, an interaction in which a message is transmitted first from the HMI (an interaction in which a user authentication request is transmitted) is specified. Here, the guess of which message is related from the cause of the threat may be performed based on a rule created in advance, or may be performed by a logic set in the occurrence location identifying unit 22.
The occurrence location specifying unit 22 writes the specified interaction in the memory 12 together with a threat that may occur for the interaction.

(Step S3 in FIG. 2: Detailed identification processing)
The detail specifying unit 23 specifies the process for realizing the interaction specified in step S <b> 2 based on the detailed design models 33 to 35 indicating the process for realizing the interaction indicated by the outline design model 31. That is, the detail specification part 23 specifies the corresponding part of the detailed design models 33-35 corresponding to the interaction specified by step S2.

Specifically, the detail specifying unit 23 reads from the memory 12 the interaction specified in step S2 and the threat that may occur with respect to the interaction. Further, the detail specifying unit 23 reads the outline design model 31 and the detailed design models 33 to 35 from the memory 12. The detail specifying unit 23 specifies the corresponding part of the detailed design model 33 based on the identifier assigned to the interaction. For example, the detail specifying unit 23 specifies that the processing from the Stop command to the response in FIG. 3 is from Command (Stop) to Command Response in FIG. Further, the detail specifying unit 23 specifies that the OK processing from the user authentication request in FIG. 3 is represented by UserAuthRequest from UserAuthRequest in FIG.
The detail specifying unit 23 specifies corresponding portions in the detailed design models 34 and 35 corresponding to the corresponding portions in the specified detailed design model 33. This can be easily specified from the name of the corresponding part in the detailed design model 33.
A threat that may occur with respect to an interaction corresponding to a corresponding location is defined as a threat corresponding to the corresponding location. The detail identification unit 23 writes the identified corresponding location in the memory 12 together with the threat corresponding to the corresponding location.

  The establishment determination unit 24 executes the processing from step S4 to step S6 for the processing of each corresponding location specified in step S3.

(Step S4 in FIG. 2: establishment determination process)
The establishment determination unit 24 determines whether or not the threat is established in the processing of the target corresponding portion based on the inspection rule indicating the determination condition as to whether or not the threat is established for each threat factor. The inspection rule is stored in advance in the storage 13.

Specifically, the establishment determination unit 24 reads the inspection rule from the storage 13. In addition, the establishment determination unit 24 reads the target corresponding portion and the threat corresponding to the target corresponding portion from the memory 12. The establishment determination unit 24 refers to the threat information 32 and identifies a threat factor corresponding to the corresponding location. The establishment determination unit 24 determines whether or not the target corresponding portion satisfies the determination condition indicated by the inspection rule for the threat factor corresponding to the target corresponding portion.
For example, assume that an inspection rule as shown in FIG. 11 is read. As shown in FIG. 4, the threat factor corresponding to the corresponding location identified in step S23 is an unauthenticated transmission message. In the inspection rule shown in FIG. 11, when the threat factor is an unauthenticated transmission message, there are two determination conditions for attacks, ie, no user authentication / bypass and session / authentication information guessing as attack methods. ing. Therefore, the establishment determination unit 24 determines whether or not the corresponding portion of interest satisfies each of the two determination conditions illustrated in FIG. 11 for each corresponding portion. In FIG. 11, the determination condition indicates a condition in which the attack is not established.

  For the user authentication no / bypass attack, (A1) or (A2) is shown as a condition that the attack is not established. (A1) User authentication processing for comparing the PASSWORD type data included in the message is performed. (A2) SESSIONID type data paid out in the user authentication process is included in the message.

The first corresponding location, UserAuthRequest to UserAuthResponse in FIG. 5, is determined as follows.
UserAuth () is performed from UserAuthRequest to UserAuthResponse. In the activity diagram of UserAuth () shown in FIG. 7, a Password type argument password that inherits the PASSWORD type data format is input as an argument of UserCheck (). And the comparison with the information acquired by GetUserPassword () is made. Therefore, the establishment determination unit 24 determines that the condition (A1) in which the attack is not established is satisfied in this process, and no user authentication / bypass attack is established.

The second corresponding location, Command (Stop) to Command Response in FIG. 5, is determined as follows.
From Command (Stop) to Command Response, as shown in FIGS. 6 and 10, data called sessionid is included, and this data is included as an argument of PowerControl (). The value of this argument is used as an argument of isValidID () in the activity diagram of PowerControl (). When the result of isValidID () is True, SetPower () that affects the field device is called. That is, the value of the sessionid argument affects the execution of SetPower (). Here, before sending the Stop command, a value to be paid out is returned as a result of comparing the PASSWORD type data. From this situation, it is recognized that the sessionid data is inherited in the sessionid. Therefore, the success determination unit 24 determines that the attack is not satisfied in this process (A2) and that no user authentication / bypass attack is satisfied.

For the session / authentication information guessing attack, it is indicated that (B1) the session ID is a random number or the length of the password is 8 or more as a condition that the attack is not established.
From the activity diagram of CreateSessionId () in FIG. 8 and the activity diagram of SendTcpData () shown in FIG. . Therefore, the establishment determination unit 24 determines that the guess attack of the session / authentication information is established for any corresponding portion.

(Step S5: Branch processing)
The establishment determination unit 24 advances the process to step S6 when it is determined in step S4 that the attack is established. On the other hand, the establishment determination unit 24 skips step S6 when it is determined in step S4 that the attack is not established.

(Step S6: Output process)
The establishment determination unit 24 outputs the processing of the target corresponding portion and information on the threat corresponding to the corresponding portion.
Specifically, the establishment determination unit 24 displays, on the display device or the like, processing of the target corresponding portion and information regarding the threat corresponding to the corresponding portion via the communication interface 14. For example, the establishment determination unit 24 may explicitly display the corresponding portion on the detailed design models 33 to 35.

  Here, only when it is determined that an attack has been established, the corresponding location is output. However, even if the attack is not established, a corresponding location or the like may be output. At this time, whether or not it is determined that an attack is established may also be output.

*** Effects of Embodiment 1 ***
As described above, in the threat identification device 10 according to the first exemplary embodiment, the interaction that may cause a threat is identified in the interaction indicated by the general design model, and the interaction identified in the detailed design model is identified. A process corresponding to is identified. As a result, it is possible to identify a process that may cause a threat. By specifying a process having a system vulnerability, the system security design can be facilitated.

  Further, the threat identification device 10 according to Embodiment 1 determines whether or not a threat is established by the identified process. Thereby, the presence or absence of the vulnerability can be accurately determined.

*** Other configurations ***
<Modification 1>
The threat information 32 may indicate a use case in which the threat occurs for each threat among a plurality of use cases indicating the relationship between the constituent elements. For example, a plurality of use cases indicating the relationship between the constituent elements are prepared in advance, and the threat information 32 indicates an identifier of the use case in which the threat occurs for each threat.
In this case, the occurrence location specifying unit 22 may generate a threat by specifying an interaction corresponding to the use case indicated by the threat information 32 among the interactions between the components indicated by the general design model 31. Identify potential interactions.

<Modification 2>
In the first embodiment, each functional component is realized by software. However, as Modification 2, each functional component may be realized by hardware. The second modification will be described with respect to differences from the first embodiment.

With reference to FIG. 12, the structure of the threat identification apparatus 10 which concerns on the modification 2 is demonstrated.
When each functional component is realized by hardware, the threat identification device 10 includes an electronic circuit 15 instead of the processor 11, the memory 12, and the storage 13. The electronic circuit 15 is a dedicated circuit that realizes the functions of the functional components, the memory 12, and the storage 13.

Examples of the electronic circuit 15 include a single circuit, a composite circuit, a programmed processor, a parallel programmed processor, a logic IC, a GA (Gate Array), an ASIC (Application Specific Integrated Circuit), and an FPGA (Field-Programmable Gate Array). is assumed.
Each functional component may be realized by one electronic circuit 15 or may be realized by distributing each functional component to a plurality of electronic circuits 15.

<Modification 3>
As a third modification, some of the functional components may be realized by hardware, and other functional components may be realized by software.

  The processor 11, the memory 12, the storage 13, and the electronic circuit 15 are called processing circuits. That is, the function of each functional component is realized by the processing circuit.

  DESCRIPTION OF SYMBOLS 10 Threat identification apparatus, 11 Processor, 12 Memory, 13 Storage, 14 Communication interface, 15 Electronic circuit, 21 Reception part, 22 Generation | occurrence | production location identification part, 23 Detailed identification part, 24 Establishment determination part, 31 Outline design model, 32 Threat information 33 Detailed design model, 34 Detailed design model, 35 Detailed design model.

Claims (8)

Based on the outline design model indicating the interaction between the components constituting the system and the threat information indicating the component that may cause the threat, there is a possibility that the threat is generated in the component constituting the system. An occurrence location identifying part that identifies an interaction;
A threat identification device comprising: a detail identification unit that identifies a process that realizes an interaction identified by the occurrence location identification unit based on a detailed design model that represents a process that realizes an interaction indicated by the outline design model. The threat information indicates an information asset in which the threat occurs for each threat,
The occurrence location specifying unit specifies an interaction that may cause a threat by specifying an interaction using an information asset indicated by the threat information among the interactions indicated by the outline design model. The threat identification device according to claim 1, comprising: The threat information indicates a factor that causes the threat for each threat,
The occurrence location identifying unit includes identifying an interaction that may cause a threat by identifying an interaction corresponding to a factor indicated by the threat information among the interactions indicated by the outline design model. The threat identification device according to claim 1 or 2. The threat information indicates a use case in which the threat occurs for each threat among a plurality of use cases indicating the relationship between the constituent elements,
The occurrence location identifying unit is an interaction that may generate a threat by identifying an interaction corresponding to a use case indicated by the threat information among interactions between components indicated by the outline design model. The threat identification device according to any one of claims 1 to 3, further comprising: The threat identification device further includes:
An establishment determination unit that determines whether a threat is established by the process specified by the detailed identification unit based on an inspection rule indicating a determination condition as to whether or not the threat is established for each threat factor. 5. The threat identification device according to any one of 1 to 4. The inspection rule indicates the determination condition based on data used in processing,
The detailed design model indicates the specifications of data used in processing,
The establishment determination unit determines whether or not a threat is established in the process specified by the detail specification unit, based on whether or not the data specification indicated by the detailed design model satisfies the determination condition indicated by the inspection rule. The threat identification device according to claim 5. Based on the outline design model in which the occurrence location identifying unit indicates the interaction between the components constituting the system and the threat information indicating the components that may cause the threat, the threat in the components constituting the system Identify interactions that may occur,
A threat identification method in which a detailed identification unit identifies a process for realizing an interaction identified by the occurrence location identification unit based on a detailed design model indicating a process for realizing an interaction indicated by the outline design model. Based on the outline design model indicating the interaction between the components constituting the system and the threat information indicating the component that may cause the threat, there is a possibility that the threat is generated in the component constituting the system. An occurrence location identifying part that identifies an interaction;
A threat identifying program that causes a computer to execute a detail identifying unit that identifies a process that realizes an interaction identified by the occurrence location identifying unit based on a detailed design model that represents a process that realizes the interaction indicated by the outline design model .

Images