WO2019142469A1 - セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム - Google Patents

セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム Download PDF

Info

Publication number
WO2019142469A1
WO2019142469A1 PCT/JP2018/041818 JP2018041818W WO2019142469A1 WO 2019142469 A1 WO2019142469 A1 WO 2019142469A1 JP 2018041818 W JP2018041818 W JP 2018041818W WO 2019142469 A1 WO2019142469 A1 WO 2019142469A1
Authority
WO
WIPO (PCT)
Prior art keywords
security
model
processing
processes
database
Prior art date
Application number
PCT/JP2018/041818
Other languages
English (en)
French (fr)
Inventor
俊 日夏
孝一 清水
武 植田
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to JP2019538449A priority Critical patent/JP6632777B2/ja
Priority to TW108101124A priority patent/TW201933165A/zh
Publication of WO2019142469A1 publication Critical patent/WO2019142469A1/ja

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12Protecting executable software
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/54Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by adding security routines or objects to programs

Definitions

  • the present invention relates to a security design device, a security design method, and a security design program.
  • model-based development technique which automatically generates source code based on a program specification described using a block diagram or a model.
  • a technology for designing security functions of a system using model-based development technology so that codes including security functions can be automatically generated.
  • Patent Document 1 proposes a technique for linking a model-based development system and a threat analysis system.
  • the threat analysis system displays threat list data indicating multiple threats to the control model by extracting data of the applicable threat from the threat database for individual elements of the control model created by the model-based development system. Create and output
  • Patent Document 1 Although it is possible to specify the location where the security function should be introduced at the device level which is an element of the control model, it is not possible to specify the location where the security function is introduced at the processing level. In order to provide tools that can implement appropriate security functions without expert knowledge, it is necessary to be able to efficiently introduce security functions at the processing level.
  • the present invention aims at efficiently introducing security functions at the processing level.
  • the security design device is When an input model defining a processing procedure of a program is input, the input is selected from among the plurality of security processes by referring to a security database which defines a plurality of security processes respectively executed to cope with threats.
  • a countermeasure introduction unit that selects one or more security processes to be introduced into the process procedure defined by the model, and outputs an output model that defines the process procedure of the program after introducing the selected security process; If the security processing selected by the countermeasure introduction part overlaps the introduction location in the processing procedure of the program and includes two or more security processing executed to cope with the same threat.
  • a redundancy checker that excludes at least one security process of the two or more security processes from being introduced into the process defined by the output model.
  • one or more security processes to be introduced are selected from the plurality of security processes defined by the security database. If the selected security processes include duplicate deployments at the process level and include more than one security process to be performed to address the same threat, the two or more security processes At least one of the security processes is excluded from deployment targets. Therefore, according to the present invention, security functions can be efficiently introduced at the processing level.
  • FIG. 1 is a block diagram showing a configuration of a security design device according to a first embodiment.
  • 6 is a table showing a configuration example of a security database of the security designing device according to the first embodiment.
  • 6 is a flowchart showing the operation of the security design device according to the first embodiment.
  • FIG. 2 shows an example of a model according to Embodiment 1; The table which shows the configuration example of the security database of the security design device which relates to the deformation example of form 1 of execution.
  • FIG. 7 shows an example of a model according to a modification of the first embodiment.
  • 6 is a table showing a configuration example of a security database of the security designing device according to the second embodiment. 6 is a flowchart showing the operation of the security design device according to the second embodiment.
  • FIG. 1 is a block diagram showing a configuration of a security design device according to a first embodiment.
  • FIG. 7 shows an example of a model according to Embodiment 2;
  • FIG. 7 is a block diagram showing the configuration of a security design device according to a third embodiment.
  • 12 is a table showing a configuration example of a security database of the security designing device according to the third embodiment. 12 is a flowchart showing the operation of the security design device according to the third embodiment.
  • FIG. 7 is a view showing an example of a model according to Embodiment 3;
  • FIG. 14 is a block diagram showing the configuration of a security design device according to a fourth embodiment.
  • 16 is a table showing an example of the configuration of a security database for high importance information assets according to the fourth embodiment.
  • 16 is a table showing an example of the configuration of a security database for low importance information assets according to the fourth embodiment.
  • FIG. 15 is a flowchart showing the operation of the security design device according to the fourth embodiment.
  • FIG. 18 is a view showing an example of model change by grouping by the security design device according to the fourth embodiment.
  • FIG. 18 is a view showing an example of model change by grouping by the security design device according to the fourth embodiment.
  • FIG. 18 is a view showing an example of model change by grouping by the security design device according to the fourth embodiment.
  • FIG. 14 is a block diagram showing the configuration of a security design device according to a fifth embodiment.
  • 16 is a table showing an example of configuration of a security database for low importance information assets according to the fifth embodiment.
  • 15 is a flowchart showing the operation of the security design device according to the fifth embodiment.
  • FIG. 18 is a view showing an example of model change by grouping by the security design device according to the fifth embodiment.
  • Embodiment 1 The present embodiment will be described with reference to FIGS. 1 to 4.
  • the security design device 10 is a computer.
  • the security design device 10 includes a processor 11 and other hardware such as a memory 12, a communication device 13, an input device 14 and a display 15.
  • the processor 11 is connected to other hardware via a signal line to control these other hardware.
  • the security design device 10 includes a countermeasure introduction unit 21, a security database 22, and a redundancy inspection unit 23.
  • the functions of the countermeasure introduction unit 21 and the redundancy check unit 23 are realized by software.
  • the security database 22 is built on the memory 12 in the present embodiment, but may be built on an auxiliary storage device described later, or may be built outside the security design device 10.
  • the processor 11 is a device that executes a security design program.
  • the security design program is a program for realizing the functions of the countermeasure introduction unit 21 and the redundancy check unit 23.
  • the processor 11 is, for example, a CPU.
  • CPU is an abbreviation for Central Processing Unit.
  • the memory 12 is a device that stores a security design program.
  • the memory 12 is, for example, a RAM, a flash memory, or a combination thereof.
  • RAM is an abbreviation for Random Access Memory.
  • the communication device 13 includes a receiver that receives data input to the security design program, and a transmitter that transmits data output from the security design program.
  • the communication device 13 is, for example, a communication chip or a NIC.
  • NIC is an abbreviation for Network Interface Card.
  • the input device 14 is a device operated by the user for inputting data into the security design program.
  • the input device 14 is, for example, a mouse, a keyboard, a touch panel, or some or all combinations of these.
  • the display 15 is a device that displays data output from the security design program on a screen.
  • the display 15 is, for example, an LCD.
  • LCD is an abbreviation of Liquid Crystal Display.
  • the security design program is read from the memory 12 into the processor 11 and executed by the processor 11. Not only the security design program but also the OS is stored in the memory 12. "OS" is an abbreviation of Operating System.
  • the processor 11 executes the security design program while executing the OS. Note that part or all of the security design program may be incorporated into the OS.
  • the security design program and the OS may be stored in the auxiliary storage device.
  • the auxiliary storage device is, for example, an HDD, a flash memory, or a combination thereof. "HDD” is an abbreviation of Hard Disk Drive.
  • the security design program and the OS when stored in the auxiliary storage device, are loaded into the memory 12 and executed by the processor 11.
  • the security design device 10 may include a plurality of processors that replace the processor 11. These multiple processors share the execution of the security design program.
  • Each processor is, for example, a CPU.
  • Data, information, signal values and variable values to be used, processed or output by the security design program are stored in the memory 12, the auxiliary storage device, or a register or cache memory in the processor 11.
  • the security design program is a program that causes a computer to execute the processing performed by the countermeasure introduction unit 21 and the redundancy inspection unit 23 as the countermeasure introduction processing and the redundancy inspection processing, respectively.
  • the security design program may be recorded and provided on a computer readable medium, may be stored and provided on a recording medium, and may be provided as a program product.
  • the security design device 10 may be configured by one computer or may be configured by a plurality of computers. When the security design device 10 is configured of a plurality of computers, the functions of the countermeasure introduction unit 21 and the redundancy inspection unit 23 may be distributed to each computer and realized.
  • FIG. 1 An exemplary configuration of the security database 22 is shown in FIG.
  • the security database 22 is a database that defines a plurality of security processes that are respectively executed to deal with threats. It is assumed that the security database 22 can cover all possible threats. Examples of threats include tampering and eavesdropping. Each security process exerts a security function as a countermeasure against threats. Examples of security features include tampering detection, encryption and decryption, and authentication. For each security feature, the definition of the threat being addressed and the point of introduction at the process level is maintained. That is, the security database 22 defines, for each of a plurality of security processes, an introduction point and a threat to be dealt with by the security process introduced to the introduction point.
  • FIG. 2 describes an example of a definition in natural language, a definition in a format easily interpretable by a program or a model may be applied.
  • the user may use software to design software without considering security.
  • step S101 the input model M1 created by the user is input to the security design device 10.
  • step S102 the countermeasure introduction unit 21 stores the input model M1 in the memory 12 as the update model M2. Based on the security database 22, the countermeasure introduction unit 21 adds the security function that can be introduced to the update model M2 to all locations.
  • the countermeasure introduction unit 21 automatically introduces a security function to the input model M1 created by the user.
  • the function added by the countermeasure introduction unit 21 is deleted if it is determined that the function is a redundant function according to the result of the inspection in the redundancy inspection unit 23 described later.
  • the models such as the input model M1 and the update model M2 are processing flow level models like a flowchart.
  • the security database 22 stores information used when the countermeasure introduction unit 21 introduces a security function to the update model M2.
  • step S103 the redundancy checking unit 23 performs model checking. Specifically, the redundancy checking unit 23 checks the presence or absence of redundancy in the update model M2.
  • step S104 if there is no redundancy, in step S105, the countermeasure introduction unit 21 outputs the update model M2 at that time as an output model M3. Then, the process ends.
  • step S104 If there is redundancy in step S104, the redundancy check unit 23 deletes one of the redundant security functions in step S106. Then, in step S103, the redundancy checking unit 23 checks the model again.
  • the redundancy checking unit 23 verifies the redundancy of the security function with respect to the update model M2.
  • a verification method in the present embodiment, a method is used in which it is confirmed whether there is an overlap in the threats to be dealt with when a plurality of security functions are continuously located in the same place.
  • a method of checking whether the same security function is included more than necessary in the same model, a method of converting the created model into a formal language to verify redundancy, or other methods are used. May be
  • the input model M1 shown as an example here is a model of control software of a simple field device.
  • the input model M1 is a processing model in which the device is stopped and ended when the control software receives the stop command as an input after the device is started.
  • the countermeasure introduction unit 21 collates the input model M1 with the security database 22 of FIG. 2 and introduces all the installable security functions. Thereby, the update model M2 is obtained.
  • the redundancy checking unit 23 performs model checking on the update model M2. If it is confirmed that there is redundancy, the redundancy checking unit 23 determines a candidate to be deleted.
  • a method of checking the redundancy a method of checking the presence or absence of duplication of the threat to be dealt with in the case where a plurality of security functions are located in the same place is used.
  • the installation point is determined for each process as "immediately after startup” and “immediately before input”.
  • a function is introduced to the actual model, two or more functions may be added to the same place in different places on the security database 22, such as immediately after the start of the update model M2 and immediately before the input. .
  • the update model M2 includes security processing P1 and security processing P2 between immediately after activation and immediately before input, security processing P3 and security processing P4 immediately after input and immediately before branching, and immediately after branching to immediately before termination. Between security processing P5 and security processing P6.
  • Security processing P1, security processing P2, security processing P3, security processing P4, security processing P5 and security processing P6 are processing having the functions of security 1, security 2, security 3, security 4, security 5, and security 6, respectively. .
  • the functions to be taken against the threat 3 include security 3, security 4 and security 6.
  • the security processing P3 and the security processing P4 continue at the same position. Therefore, it is considered that one is unnecessary.
  • the redundancy checking unit 23 deletes the security processing P4 from the update model M2. Thus, an output model M3 is obtained.
  • the redundancy inspection unit 23 compares the positions in the security database 22 and deletes the function located below but deletes the function located above. May be Alternatively, when comparing the two security functions, the redundancy inspection unit 23 may delete the function whose execution order is earlier in the update model M2, or delete the function whose execution order is later in the update model M2. You may
  • the countermeasure introduction unit 21 receives the input model M1 that defines the processing procedure of the program.
  • the countermeasure introduction unit 21 refers to the security database 22 and introduces the processing procedure defined by the input model M1 out of a plurality of security processes defined by the security database 22. Select one or more security actions.
  • the countermeasure introduction unit 21 outputs an output model M3 that defines the processing procedure of the program after introducing the selected security processing.
  • the “program” is a control program of a field device in the present embodiment, it may be any type of program such as a control program of a vehicle-mounted device.
  • the “one or more security processes” is a security process in which the introduction site defined by the security database 22 is present in the process procedure defined by the input model M1.
  • “one or more security processes” are security process P1, security process P2, security process P3, security process P4, security process P5, and security process P6.
  • the redundancy inspection unit 23 has two or more security processes executed to cope with the same threat, in the security process selected by the countermeasure introduction unit 21, in which the introduction position in the processing procedure of the program is duplicated. To see if it contains. If two or more such security processes are included, the redundancy inspection unit 23 adds at least one of the two or more security processes to the process procedure defined by the output model M3. Exclude from introduction. In the present embodiment, as the “at least one security process”, the redundancy inspection unit 23 excludes security processes other than one of the “two or more security processes” from the introduction target.
  • two or more security processes are security processes that are sequentially executed in the process procedure of the program and in which the threats defined by the security database 22 coincide.
  • two or more security processes are the security process P3 and the security process P4 corresponding to the threat 3 in the security database 22 of FIG.
  • the redundancy inspection unit 23 determines whether to exclude each of the “two or more security processes” from the introduction target according to the registered position of the “two or more security processes” in the security database 22. Do. In the example of FIG. 4, the redundancy checking unit 23 excludes the security processing P4 below the security database 22 of FIG. 2 among the security processing P3 and the security processing P4 from the introduction targets.
  • the redundancy checking unit 23 determines whether each of the “two or more security processes” is excluded from the introduction target according to the execution order of the “two or more security processes” in the program processing procedure. Good.
  • the redundancy inspection unit 23 may be considered to exclude the security processing P4 to be executed later among the security processing P3 and the security processing P4 from the introduction targets.
  • the security introduction points are narrowly defined as “immediately after start up” and “immediately before stop”, but in the security database 22 of FIG.
  • the introduction point can be widely determined, as in
  • This update model M2 includes security processing P1 and security processing P2 and security processing P3a immediately after activation and immediately before input, security processing P3b and security processing P4 immediately after input and immediately before branching, and immediately before stopping immediately after branching
  • the security process P3c, the security process P5, and the security process P6 are included between The security processing P3a, the security processing P3b, and the security processing P3c are all processing having a security 3 function.
  • the security process P1, the security process P2, the security process P4, the security process P5, and the security process P6 are the same processes as the example of FIG.
  • the functions to be taken against the threat 3 include security 3, security 4 and security 6.
  • the security processing P3a, security processing P3b, security processing P3c, security processing P4 and security processing P6 corresponding to them the security processing P3b and the security processing P4 are continuous at the same position. Therefore, it is considered that one is unnecessary.
  • the redundancy checking unit 23 deletes the security processing P4 from the update model M2. Also, the security processing P3c and the security processing P6 are continuous at the same position. Therefore, it is considered that one is unnecessary.
  • the redundancy checking unit 23 deletes the security processing P6 from the update model M2. Thereby, the output model M3 of FIG. 6 is obtained.
  • one or more security processes to be introduced are selected from the plurality of security processes defined by the security database 22. If the selected security processes include duplicate deployments at the process level and include more than one security process to be performed to address the same threat, the two or more security processes At least one of the security processes is excluded from deployment targets. Therefore, according to the present embodiment, the security function can be efficiently introduced at the processing level.
  • all the security functions that can be introduced based on the security database 22 are introduced into the input model M1, and deletion of the security function is repeated based on the model inspection. According to the present embodiment, by introducing the security function without specifying the vulnerability, it is possible to introduce an appropriate security function at the level of the processing flow without duplication.
  • the functions of the countermeasure introduction unit 21 and the redundancy inspection unit 23 are realized by software, but as another configuration example, the functions of the countermeasure introduction unit 21 and the redundancy inspection unit 23 are software and hardware. It may be realized by the combination of That is, part of the functions of the countermeasure introduction unit 21 and the redundancy check unit 23 may be realized by dedicated hardware, and the remaining may be realized by software.
  • the dedicated hardware may be, for example, a single circuit, a complex circuit, a programmed processor, a parallel programmed processor, a logic IC, a GA, an FPGA, an ASIC, or some or all of these combinations.
  • IC is an abbreviation for Integrated Circuit.
  • GA is an abbreviation of Gate Array.
  • FPGA is an abbreviation of Field-Programmable Gate Array.
  • ASIC is an abbreviation for Application Specific Integrated Circuit.
  • the processor 11 and dedicated hardware are both processing circuits. That is, regardless of whether the functions of the countermeasure introduction unit 21 and the redundancy inspection unit 23 are realized by software or a combination of software and hardware, the operations of the countermeasure introduction unit 21 and the redundancy inspection unit 23 Is performed by the processing circuit.
  • FIG. 1 An exemplary configuration of the security database 22 is shown in FIG.
  • the security database 22 is a database that defines a plurality of security processes that are respectively executed to deal with threats.
  • the security database 22 defines priorities for at least some of the security processes among the plurality of security processes.
  • FIG. 7 describes an example of a definition in natural language, a definition in a format easily interpretable by a program or a model may be applied.
  • step S201 to step S205 are the same as the processes of step S101 to step S105 in the first embodiment, and thus the description thereof is omitted.
  • step S204 If there is redundancy in step S204 and there is only one security function to be a deletion candidate in step S206, the redundancy check unit 23 deletes the security function in step S207. Then, in step S203, the redundancy checking unit 23 checks the model again.
  • step S204 If there is redundancy in step S204 and there are a plurality of security functions to be deletion candidates in step S206, the redundancy check unit 23 selects a deletion candidate with a low priority in step S208. In step S207, the redundancy check unit 23 deletes the selected security function. Then, in step S203, the redundancy checking unit 23 checks the model again.
  • the countermeasure introduction unit 21 collates the input model M1 with the security database 22 of FIG. 7 and introduces all the installable security functions. Thereby, the update model M2 is obtained.
  • the redundancy checking unit 23 performs model checking on the update model M2. If it is confirmed that there is redundancy, the redundancy checking unit 23 determines a candidate to be deleted.
  • a method of checking the redundancy a method of checking the presence or absence of duplication of a threat to be dealt with in the case where a plurality of security functions are located at the same place is used.
  • the update model M2 has security processing P1 and security processing P2 between immediately after activation and immediately before input, and security processing P3 and security between immediately after input and immediately before branching.
  • a process P4 has a security process P5 and a security process P6 immediately after the branch and immediately before the stop.
  • Security processing P1, security processing P2, security processing P3, security processing P4, security processing P5 and security processing P6 are processing having the functions of security 1, security 2, security 3, security 4, security 5, and security 6, respectively. .
  • the functions to be taken against the threat 3 include security 3, security 4 and security 6.
  • the security processing P3 and the security processing P4 continue at the same position. Therefore, it is considered that one is unnecessary.
  • the security database 22 of FIG. 7 since the priorities of the security 3 and the security 4 are “2” and “1”, respectively, the security processing P4 has a higher priority. Therefore, unlike the example of FIG. 4, the redundancy check unit 23 deletes the security process P3 from the update model M2. Thus, an output model M3 is obtained.
  • the redundancy inspection unit 23 determines whether or not each of “two or more security processes” is excluded from the introduction targets according to the priority order defined by the security database 22. Do. In the example of FIG. 9, the redundancy inspection unit 23 excludes the security processing P3 having a lower priority in the security database 22 of FIG. 7 among the security processing P3 and the security processing P4 from the introduction targets.
  • the security design device 10 includes an evaluation unit 24 in addition to the countermeasure introduction unit 21, the security database 22, and the redundancy inspection unit 23.
  • the functions of the countermeasure introduction unit 21, the redundancy inspection unit 23, and the evaluation unit 24 are realized by software.
  • FIG. 22 A configuration example of the security database 22 is shown in FIG.
  • the security database 22 is a database that defines a plurality of security processes that are respectively executed to deal with threats.
  • the security database 22 defines costs for each of a plurality of security processes. Examples of costs include encryption key lengths and the time taken to perform security functions.
  • definitions of a plurality of types of costs may be held.
  • FIG. 11 Although an example of definition in natural language is described in FIG. 11, a definition in a format easily interpretable by a program or a model may be applied.
  • step S300 the evaluation unit 24 sets and defines an evaluation value calculated from the cost based on the user's request in the model to be designed, such as performance and security, and registers the evaluation value in the security database 22.
  • Performance is the overall processing speed.
  • steps S301 to S305 are the same as the processes in steps S101 to S105 in the first embodiment, and thus the description thereof is omitted.
  • step S304 If there is redundancy in step S304 and there is only one security function to be a deletion candidate in step S306, the redundancy check unit 23 deletes the security function in step S307. Then, in step S303, the redundancy checking unit 23 checks the model again.
  • the evaluation unit 24 calculates an evaluation value when each candidate is deleted in step S308. Specifically, based on the definition of the cost held in the security database 22, the evaluation unit 24 calculates the evaluation value of the model to which the security function is introduced. Examples of evaluation include confirmation of the strength of performance and security.
  • the evaluation value may be a simple addition value or multiplication value of costs, or may be a value obtained by a function uniquely defined by the user.
  • the redundancy inspection unit 23 compares the evaluation values of the models calculated by the evaluation unit 24 and selects a deletion candidate with a low evaluation value. In step S207, the redundancy check unit 23 deletes the selected security function. Then, in step S203, the redundancy checking unit 23 checks the model again.
  • the countermeasure introduction unit 21 collates the input model M1 with the security database 22 of FIG. 11 and introduces all the installable security functions. Thereby, the update model M2 is obtained.
  • the redundancy checking unit 23 performs model checking on the update model M2. If it is confirmed that there is redundancy, the redundancy checking unit 23 determines a candidate to be deleted.
  • a method of checking the redundancy a method of checking the presence or absence of duplication of a threat to be dealt with in the case where a plurality of security functions are located at the same place is used.
  • the update model M2 has security processing P1 and security processing P2 between immediately after activation and immediately before input, and security processing P3 and security between immediately after input and immediately before branching.
  • a process P4 has a security process P5 and a security process P6 immediately after the branch and immediately before the stop.
  • Security processing P1, security processing P2, security processing P3, security processing P4, security processing P5 and security processing P6 are processing having the functions of security 1, security 2, security 3, security 4, security 5, and security 6, respectively. .
  • the functions to be taken against the threat 3 include security 3, security 4 and security 6.
  • the security processing P3 and the security processing P4 continue at the same position. Therefore, it is considered that one is unnecessary. Therefore, an output model M3a from which the security processing P4 has been deleted and an output model M3b from which the security processing P3 has been deleted can be considered as models to be obtained.
  • the evaluation unit 24 calculates an evaluation value defined by the user for each candidate.
  • the redundancy checking unit 23 adopts a model with a high evaluation value.
  • the evaluation value defined by the user is the reciprocal of the sum of the costs of the security functions of the model
  • the evaluation value of the output model M3a is 1 / (C1 + C2 + C3 + C5 + C6)
  • the evaluation value of the output model M3b is 1 / (C1 + C2 + C4 + C5 + C6) It becomes. Therefore, the function to delete is determined depending on the magnitude of C3 and C4. If C3 ⁇ C4, the redundancy checking unit 23 deletes the security processing P4 from the update model M2. Thus, an output model M3a is obtained. If C3> C4, the redundancy checking unit 23 deletes the security processing P3 from the update model M2. Thus, an output model M3b is obtained.
  • the redundancy checking unit 23 may delete the security processing P4 from the update model M2 or may delete the security processing P3.
  • the function to be deleted may be determined based on the position on the security database 22 as in the first embodiment. Similarly, the function to be deleted may be determined based on the priority.
  • the redundancy inspection unit 23 determines whether or not each of the “two or more security processes” is to be excluded from the introduction target based on the cost defined by the security database 22. .
  • the redundancy inspection unit 23 excludes the security processing of the one with the lower cost in the security database 22 of FIG. 11 among the security processing P3 and the security processing P4 from the introduction targets.
  • the security function can be introduced while taking into account the user's request in terms of security and performance. By introducing the security function without identifying the vulnerability location, checking the model for verification of the vulnerability and confirming the user's request, the appropriate security function at the process flow level is not duplicated. It can be introduced in places.
  • the functions of the countermeasure introduction unit 21, the redundancy inspection unit 23, and the evaluation unit 24 are realized by software, but the same as the other configuration examples of the first embodiment.
  • the functions of the countermeasure introduction unit 21, the redundancy inspection unit 23, and the evaluation unit 24 may be realized by a combination of software and hardware.
  • an information asset is an element which constitutes a model.
  • an information asset is a variable, constant, process, routine, function or function used in the model.
  • the importance of the information asset is the value of the information asset in the model.
  • the degree of importance may be characteristics or attributes such as “security strength”, “sensitivity”, “completeness”, “availability”, and “vulnerability”.
  • the importance may be a characteristic or attribute such as performance (overall processing speed), execution frequency, frequency of use of resources (CPU, memory, etc.), time of use of resources, usage of resources.
  • each security DB holds security functions that differ depending on the strength of the security and rules for its introduction.
  • the security DB 22 is used properly depending on the importance of the information asset to be protected from threats.
  • FIG. 14 is a block diagram showing a security design device 10 according to the embodiment of the present invention.
  • the security design device 10 of FIG. 14 includes a processing classification unit 25 in addition to the countermeasure introduction unit 21, the security DB 22, and the redundancy inspection unit 23 similar to the first embodiment.
  • the processing classification unit 25 inputs the information asset importance degree information L1 handled in the model.
  • Information asset importance information L1 is information indicating the importance of the information asset handled in the model.
  • the process classification unit 25 groups the processes in the model based on the information asset used in the model with reference to the information asset importance degree information L1.
  • the security DB 22 defines security processing according to the importance of the information asset.
  • the countermeasure introduction unit 21 selects a security process to be introduced for the processing procedure grouped by the processing classification unit 25 among the plurality of security processes, and selects the security process selected for the grouped processing procedure. Introduce.
  • the security DB 22A of FIG. 15 is a specific example of a security DB for information assets of high importance.
  • the security DB 22B in FIG. 16 is a specific example of a security DB for information assets of low importance.
  • the security DB 22A applied to highly important information assets contains many strong security functions.
  • the security DB 22B applied to information assets of low importance includes relatively weak security functions. The same function may be redundantly held among multiple security DBs.
  • the information asset importance degree information L1 is input as an input to the processing classification unit 25.
  • the information asset importance level information L1 indicates, for example, “command A: high importance level”, “command B: low importance level”, etc., and information assets included in the input model M1 and their importance levels.
  • the importance of information may be classified into a plurality of characteristics such as “sensitivity”, “completeness”, and “availability”, and a security DB corresponding to each may be prepared. Also, vulnerability information in the model may be obtained in advance and used to determine the importance of information assets.
  • the process classification unit 25 extracts and groups processes in which the same information asset is used in the input model.
  • the method of realizing grouping there is a method of extracting a process in which the same variable is used, or a method of tracking using data flow.
  • the grouped processing can be handled in the same manner as the model in the first embodiment etc., and is compared with the security DB 22 and input to the countermeasure introduction unit 21 and the redundancy inspection unit 23 in the subsequent stage.
  • the redundancy checker 23 may not operate or may not be necessary.
  • step S401 the created input model M1 and information asset importance degree information L1 are input to the security design device 10. That is, in addition to the control model to be developed, the user inputs importance level information of information assets handled in the model.
  • step S402 the security design device 10 inputs a model to the processing classification unit 25.
  • the process classification unit 25 outputs the model obtained by grouping and grouping the processes included in the model based on the information asset used in the model as the update model M2.
  • step S403 the countermeasure introduction unit 21 adds the security function that can be introduced to each group of the model for update M2 to all locations based on the security DB 22.
  • step S404 the redundancy checking unit 23 performs model checking to check the presence or absence of redundancy in the update model M2.
  • step S405 If it is determined in step S405 that there is no redundancy in the update model M2, the update model M2 at that time is output as the output model M3, and the process proceeds to step S406 to end the processing.
  • step S407 the countermeasure introduction unit 21 deletes one of the redundant security functions of the update model M2 and performs model checking again. Do.
  • the security design device 10 repeats the above processing until it can be confirmed that redundancy is completely eliminated, and outputs a model for which vulnerability measures have been taken at the processing level.
  • Model M410 shown here as an example assumes control software of a field device, receives a plurality of commands from the outside, ie, commands A and B, respectively, and transmits each command to the outside and ends the processing. It is a model. However, it is assumed that command A has high importance and command B has low importance.
  • the information asset importance degree information L1 is information indicating that the command A is high in importance and the command B is low in importance.
  • the user inputs the processing model M410 and the information asset importance degree information L1.
  • the processing classification unit 25 groups each processing based on the information asset used in each processing. Since the model M 410 has a process in which the command A is used and a process in which the command B is used, each process can be classified into two groups.
  • the process classification unit 25 classifies the model M410 into two groups, a group G421 in which the command A is used and a group G422 in which the command B is used, and outputs it as a model M420.
  • the countermeasure introduction unit 21 collates the security DB 22A of FIG. 15 with the security DB 22B of FIG. 16 with respect to the grouped model M 420, and introduces a security function that can be introduced into each group.
  • the countermeasure introduction unit 21 introduces the security function of the security DB 22A into the group G 421, introduces the security function of the security DB 22B into the group G 422, and outputs it as a model M430.
  • model checking is performed on the model M 430 as necessary to remove redundant functions. After deletion, perform model checking again to check for redundancy.
  • security is introduced at the processing level by introducing the security function without specifying the vulnerability location, confirming the presence or absence of the vulnerability by verifying the model, and confirming the importance of the information asset.
  • the functions can be introduced to the appropriate number and location without duplication.
  • the processing content of the information asset is focused.
  • the command A importance: high
  • the command B importance: low
  • the process classification unit 25 classifies the model Ma420 into two groups, that is, a group Ga421 and a group Ga422, and outputs it as a model Ma420. As such, when the calculation / calculation results of the information assets having different degrees of importance are included, they are included in the group of information assets of high importance.
  • the countermeasure introduction unit 21 collates the security DB 22A of FIG. 15 and the security DB 22B of FIG. 16 in the same manner as described above, and outputs the model Ma 430 including the security function for each information asset.
  • command A importance: high
  • command B importance: low
  • command A is used as a control variable of the branch in process Mb 413 in the middle There is.
  • the countermeasure introduction unit 21 collates the security DB 22A of FIG. 15 and the security DB 22B of FIG. 16 in the same manner as described above, and outputs a model Mb 430 including a security function for each information asset.
  • Embodiment 5 The difference between this embodiment and the fourth embodiment will be mainly described with reference to FIGS. 21 to 25.
  • processing in the model is grouped based on the information asset used in the model, and all security functions that can be introduced to the group based on the security DB are grouped. Introduce.
  • the present embodiment is characterized in that deletion or replacement of the security function is repeated based on model inspection and group evaluation in the model by cost.
  • FIG. 21 is a block diagram showing a security design device 10 according to the embodiment of the present invention.
  • the security design device 10 of FIG. 21 includes a group evaluation unit 26 in addition to the countermeasure introduction unit 21, the security DB 22, the redundancy inspection unit 23, and the processing classification unit 25 similar to the fourth embodiment.
  • the group evaluation unit 26 obtains an evaluation value of the security processing in the grouped processing procedure based on the cost defined by the security DB, and the security in the grouped processing procedure based on the evaluation value. Decide whether to exclude the process from implementation.
  • the security DB 22 stores information used when the security introduction is performed on the update model M 2 in the countermeasure introduction unit 21.
  • the security DB 22A of FIG. 22 and the security DB 22B of FIG. 23 are examples of components of the security DB 22 of FIG.
  • the security DB 22A of FIG. 22 is a specific example of a security DB for information assets with high importance.
  • the security DB 22B of FIG. 23 is a specific example of a security DB for information assets of low importance.
  • the security DB 22A and the security DB 22B hold the cost C required for function introduction in addition to the same rules for security function introduction as in the fourth embodiment.
  • the cost C the key length of encryption, the time required to execute the security function, etc. can be considered. Multiple types of costs may be held in one DB.
  • the group evaluation unit 26 calculates an evaluation value for the group of models to which the security function has been introduced, based on the cost C held in the security DB 22.
  • the purpose of the evaluation is to consider performance (total processing speed), security strength, and resource limitations such as CPU and memory.
  • the evaluation value may be a simple addition or multiplication of costs, or the user may define the function independently.
  • the group evaluation unit 26 calculates an evaluation value of the model, and confirms whether the model satisfies the user's request. If the requirement is not satisfied, the security function is deleted or replaced with another function in the countermeasure introduction unit 21. Alternatively, a method of presenting a warning to the user may be considered.
  • the redundancy checker 23 may not operate or may not be necessary.
  • step S500 based on the user's request for the model to be designed, such as performance (total processing speed), security strength, resource limitations such as CPU and memory, set and define evaluation criteria for security processing processing time Keep it.
  • step S501 the user designs software using a model without considering security, and inputs the created input model M1 and information asset importance degree information L1 to the security design device 10.
  • step S502 the security design device 10 inputs the input model M1 to the processing classification unit 25.
  • the process classification unit 25 groups the processes included in the model based on the information asset to be used, and outputs the grouped model as the update model M2.
  • step S 503 the countermeasure introduction unit 21 adds the security function that can be introduced to the update model M 2 to all the locations based on the security DB 22.
  • step S504 the redundancy checking unit 23 performs model checking to check the presence or absence of redundancy in the update model M2.
  • step S504 If it is determined in step S504 that the update model M2 has redundancy, then in step S505, the countermeasure introduction unit 21 deletes one of the redundant security functions and performs model inspection again.
  • step S507 the group evaluation unit 26 calculates an evaluation value of each group of the update model M2 at that time.
  • step S508 if it can be confirmed that the evaluation value satisfies the criteria, the countermeasure introduction unit 21 sets the update model M2 at that time as the output model M3 and proceeds to step S509 to end the processing.
  • step S506 the countermeasure introduction unit 21 deletes one security function in the update model M2 at that time, or replaces it with a security function with a low cost value, thereby making redundancy.
  • the sex checking unit 23 checks the redundancy again.
  • the security design device 10 repeats the above processing until it can confirm that there is no redundancy and that the evaluation value satisfies the standard, and outputs a model in which the security function is applied to each information asset at the processing level.
  • Model M510 shown here as an example assumes control software of a field device, receives a plurality of commands from the outside, ie, commands A and B, respectively, and transmits each command to the outside and ends the process. It is a model. However, it is assumed that command A has high importance and command B has low importance.
  • the user first defines the evaluation criteria for command A and the evaluation criteria for command B. For example, it is assumed that processing time of security processing for each command is evaluated.
  • the user defines the criteria C B0 on evaluation criteria C A0 and command B for the command A as a measure of the processing time of the security process, the real-time considerations, the processing time of the security process in each command exceeds this criterion I shall not do it.
  • the user inputs the processing model M510 as the input model M1.
  • the processing classification unit 25 groups each processing based on the information asset used in each processing.
  • the process classification unit 25 can classify each process into two groups because the model M 510 has a process in which the command A is used and a process in which the command B is used (a group of the model M 520 in FIG. 25). G521 and group G522).
  • the countermeasure introduction unit 21 collates the security DB 22A of FIG. 22 with the security DB 22B of FIG. 23 with respect to the grouped model M 520, and introduces a security function that can be introduced into each group.
  • the countermeasure introduction unit 21 introduces the security function of the security DB 22A into the group G 521, introduces the security function of the security DB 22B into the group G 522, and outputs it as a model M530.
  • the model checking is performed in the redundancy checking unit 23 to confirm the presence or absence of redundancy in the update model M2. If it is determined that the update model M2 has redundancy, the countermeasure introduction unit 21 deletes one of the redundant security functions and performs model inspection again.
  • the group evaluation unit 26 calculates an evaluation value of each group of the update model M2 at that time.
  • the group evaluation unit 26 compares the evaluation value with the evaluation standard, and it is assumed that C A > C A0 and C B ⁇ C B0 . Since C A've exceeds the reference C A0, the process of replacing either one or eliminate other handle security functions of the group G531 is needed.
  • the group evaluation unit 26 determines a security function to be removed or replaced with another process, and instructs the countermeasure introduction unit 21.
  • FIG. 25 shows an example in which the countermeasure introduction unit 21 satisfies the condition C A ⁇ C A 0 by removing the tampering detection process M 541 and obtains the model M 540.
  • the determination as to which security function is to be removed or exchanged from the group may be made by using the priority of the security function, or by using the cost value of the security function or the like. Also, the group evaluation unit 26 may not delete the security function automatically or replace the security function automatically, but the group evaluation unit 26 may present a deletion warning or an option to the user.
  • the countermeasure introduction unit 21 outputs the update model M2 at that time as an output model M3.
  • the security function can be introduced in consideration of the system performance (overall processing speed), security strength, restriction of hardware resources, and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

セキュリティ設計装置(10)において、セキュリティデータベース(22)は、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義する。対策導入部(21)は、プログラムの処理手順を定義する入力モデル(M1)が入力されると、セキュリティデータベース(22)により定義された複数のセキュリティ処理の中から、導入する1つ以上のセキュリティ処理を選択し、選択したセキュリティ処理を導入した後のプログラムの処理手順を定義する出力モデル(M3)を出力する。冗長性検査部(23)は、対策導入部(21)により選択されたセキュリティ処理の中に、導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理を導入対象から除外する。

Description

セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム
 本発明は、セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラムに関するものである。
 機器を制御する制御システムが外部ネットワークへ接続されるケースがある。そのようなケースの増加に伴い、制御システムへのサイバー攻撃が増加するおそれがある。よって、脆弱性の低減および攻撃検知等が求められている。加えて、セキュリティの専門家が不足していることが指摘されている。したがって、今後、専門知識がなくても適切なセキュリティ機能を実装可能とするツールが必要である。
 プログラム開発において、ブロック図またはモデル等を使って記述したプログラム仕様に基づいてソースコードを自動生成する「モデルベース開発技術」が提案されている。サイバー攻撃への対策として、セキュリティ機能を含めたコードを自動生成できるように、モデルベース開発技術を利用してシステムのセキュリティ機能を設計する技術が提案されている。
 特許文献1では、モデルベース開発システムと脅威分析システムとを連携させる技術が提案されている。この技術では、脅威分析システムが、モデルベース開発システムによって作成された制御モデルの個々の要素について、脅威データベースから該当する脅威のデータを抽出することにより、制御モデルに対する複数の脅威を示す脅威一覧データを作成して出力する。
特開2017-068825号公報
 特許文献1に記載の技術では、制御モデルの要素である装置レベルでセキュリティ機能を導入すべき箇所を特定することはできても、処理レベルでセキュリティ機能を導入する箇所を特定することはできない。専門知識がなくても適切なセキュリティ機能を実装可能とするツールを提供するには、処理レベルでセキュリティ機能を効率的に導入できる必要がある。
 本発明は、処理レベルでセキュリティ機能を効率的に導入することを目的とする。
 本発明の一態様に係るセキュリティ設計装置は、
 プログラムの処理手順を定義する入力モデルが入力されると、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義するセキュリティデータベースを参照して、前記複数のセキュリティ処理の中から、前記入力モデルにより定義された処理手順に導入する1つ以上のセキュリティ処理を選択し、選択したセキュリティ処理を導入した後の前記プログラムの処理手順を定義する出力モデルを出力する対策導入部と、
 前記対策導入部により選択されたセキュリティ処理の中に、前記プログラムの処理手順における導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理を、前記出力モデルにより定義される処理手順への導入対象から除外する冗長性検査部と
を備える。
 本発明では、セキュリティデータベースにより定義された複数のセキュリティ処理の中から、導入する1つ以上のセキュリティ処理が選択される。選択したセキュリティ処理の中に、処理レベルでの導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理が導入対象から除外される。したがって、本発明によれば、処理レベルでセキュリティ機能を効率的に導入することができる。
実施の形態1に係るセキュリティ設計装置の構成を示すブロック図。 実施の形態1に係るセキュリティ設計装置のセキュリティデータベースの構成例を示す表。 実施の形態1に係るセキュリティ設計装置の動作を示すフローチャート。 実施の形態1に係るモデル例を示す図。 実施の形態1の変形例に係るセキュリティ設計装置のセキュリティデータベースの構成例を示す表。 実施の形態1の変形例に係るモデル例を示す図。 実施の形態2に係るセキュリティ設計装置のセキュリティデータベースの構成例を示す表。 実施の形態2に係るセキュリティ設計装置の動作を示すフローチャート。 実施の形態2に係るモデル例を示す図。 実施の形態3に係るセキュリティ設計装置の構成を示すブロック図。 実施の形態3に係るセキュリティ設計装置のセキュリティデータベースの構成例を示す表。 実施の形態3に係るセキュリティ設計装置の動作を示すフローチャート。 実施の形態3に係るモデル例を示す図。 実施の形態4に係るセキュリティ設計装置の構成を示すブロック図。 実施の形態4に係る高重要度の情報資産用のセキュリティデータベースの構成例を示す表。 実施の形態4に係る低重要度の情報資産用のセキュリティデータベースの構成例を示す表。 実施の形態4に係るセキュリティ設計装置の動作を示すフローチャート。 実施の形態4に係るセキュリティ設計装置によるグループ化によるモデル変化例を示す図。 実施の形態4に係るセキュリティ設計装置によるグループ化によるモデル変化例を示す図。 実施の形態4に係るセキュリティ設計装置によるグループ化によるモデル変化例を示す図。 実施の形態5に係るセキュリティ設計装置の構成を示すブロック図。 実施の形態5に係る高重要度の情報資産用のセキュリティデータベースの構成例を示す表。 実施の形態5に係る低重要度の情報資産用のセキュリティデータベースの構成例を示す表。 実施の形態5に係るセキュリティ設計装置の動作を示すフローチャート。 実施の形態5に係るセキュリティ設計装置によるグループ化によるモデル変化例を示す図。
 以下、本発明の実施の形態について、図を用いて説明する。各図中、同一または相当する部分には、同一符号を付している。実施の形態の説明において、同一または相当する部分については、説明を適宜省略または簡略化する。なお、本発明は、以下に説明する実施の形態に限定されるものではなく、必要に応じて種々の変更が可能である。例えば、以下に説明する実施の形態のうち、2つ以上の実施の形態が組み合わせられて実施されても構わない。あるいは、以下に説明する実施の形態のうち、1つの実施の形態または2つ以上の実施の形態の組み合わせが部分的に実施されても構わない。
 実施の形態1.
 本実施の形態について、図1から図4を用いて説明する。
 ***構成の説明***
 図1を参照して、本実施の形態に係るセキュリティ設計装置10の構成を説明する。
 セキュリティ設計装置10は、コンピュータである。セキュリティ設計装置10は、プロセッサ11を備えるとともに、メモリ12、通信デバイス13、入力機器14およびディスプレイ15といった他のハードウェアを備える。プロセッサ11は、信号線を介して他のハードウェアと接続され、これら他のハードウェアを制御する。
 セキュリティ設計装置10は、対策導入部21と、セキュリティデータベース22と、冗長性検査部23とを備える。対策導入部21および冗長性検査部23の機能は、ソフトウェアにより実現される。セキュリティデータベース22は、本実施の形態ではメモリ12上に構築されるが、後述する補助記憶装置上に構築されてもよいし、セキュリティ設計装置10の外部に構築されてもよい。
 プロセッサ11は、セキュリティ設計プログラムを実行する装置である。セキュリティ設計プログラムは、対策導入部21および冗長性検査部23の機能を実現するプログラムである。プロセッサ11は、例えば、CPUである。「CPU」は、Central Processing Unitの略語である。
 メモリ12は、セキュリティ設計プログラムを記憶する装置である。メモリ12は、例えば、RAM、フラッシュメモリまたはこれらの組み合わせである。「RAM」は、Random Access Memoryの略語である。
 通信デバイス13は、セキュリティ設計プログラムに入力されるデータを受信するレシーバと、セキュリティ設計プログラムから出力されるデータを送信するトランスミッタとを含む。通信デバイス13は、例えば、通信チップまたはNICである。「NIC」は、Network Interface Cardの略語である。
 入力機器14は、セキュリティ設計プログラムへのデータの入力のためにユーザにより操作される機器である。入力機器14は、例えば、マウス、キーボード、タッチパネル、または、これらのうちいくつか、もしくは、すべての組み合わせである。
 ディスプレイ15は、セキュリティ設計プログラムから出力されるデータを画面に表示する機器である。ディスプレイ15は、例えば、LCDである。「LCD」は、Liquid Crystal Displayの略語である。
 セキュリティ設計プログラムは、メモリ12からプロセッサ11に読み込まれ、プロセッサ11によって実行される。メモリ12には、セキュリティ設計プログラムだけでなく、OSも記憶されている。「OS」は、Operating Systemの略語である。プロセッサ11は、OSを実行しながら、セキュリティ設計プログラムを実行する。なお、セキュリティ設計プログラムの一部または全部がOSに組み込まれていてもよい。
 セキュリティ設計プログラムおよびOSは、補助記憶装置に記憶されていてもよい。補助記憶装置は、例えば、HDD、フラッシュメモリまたはこれらの組み合わせである。「HDD」は、Hard Disk Driveの略語である。セキュリティ設計プログラムおよびOSは、補助記憶装置に記憶されている場合、メモリ12にロードされ、プロセッサ11によって実行される。
 セキュリティ設計装置10は、プロセッサ11を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、セキュリティ設計プログラムの実行を分担する。それぞれのプロセッサは、例えば、CPUである。
 セキュリティ設計プログラムにより利用、処理または出力されるデータ、情報、信号値および変数値は、メモリ12、補助記憶装置、または、プロセッサ11内のレジスタまたはキャッシュメモリに記憶される。
 セキュリティ設計プログラムは、対策導入部21および冗長性検査部23により行われる処理をそれぞれ対策導入処理および冗長性検査処理としてコンピュータに実行させるプログラムである。セキュリティ設計プログラムは、コンピュータ読取可能な媒体に記録されて提供されてもよいし、記録媒体に格納されて提供されてもよいし、プログラムプロダクトとして提供されてもよい。
 セキュリティ設計装置10は、1台のコンピュータで構成されていてもよいし、複数台のコンピュータで構成されていてもよい。セキュリティ設計装置10が複数台のコンピュータで構成されている場合は、対策導入部21および冗長性検査部23の機能が、各コンピュータに分散されて実現されてもよい。
 図2に、セキュリティデータベース22の構成例を示す。
 セキュリティデータベース22は、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義するデータベースである。セキュリティデータベース22は、想定されるすべての脅威を網羅できているとする。脅威の例としては、改竄および盗聴が挙げられる。それぞれのセキュリティ処理は、脅威への対策として、セキュリティ機能を発揮する。セキュリティ機能の例としては、改竄検知、暗号化ならびに復号、および、認証が挙げられる。各セキュリティ機能について、対処される脅威と、処理レベルにおける導入箇所との定義が保持されている。すなわち、セキュリティデータベース22は、複数のセキュリティ処理のそれぞれについて、導入箇所と、その導入箇所に導入されたセキュリティ処理によって対処される脅威とを定義している。
 なお、図2では、自然言語による定義の例を記載しているが、プログラムまたはモデルで容易に解釈が可能な形式による定義が適用されてもよい。
 ***動作の説明***
 図3を参照して、本実施の形態に係るセキュリティ設計装置10の動作を説明する。セキュリティ設計装置10の動作は、本実施の形態に係るセキュリティ設計方法に相当する。
 ユーザは、モデルを用いてセキュリティを考慮せずにソフトウェア設計を行ってよい。
 ステップS101において、ユーザにより作成された入力モデルM1がセキュリティ設計装置10に入力される。
 ステップS102において、対策導入部21は、入力モデルM1を更新用モデルM2としてメモリ12に保存する。対策導入部21は、セキュリティデータベース22を基に、更新用モデルM2に対して導入可能なセキュリティ機能を全箇所に追加する。
 このように、対策導入部21は、ユーザの作成した入力モデルM1に対して自動的にセキュリティ機能を導入する。ただし、対策導入部21により追加された機能は、後述する冗長性検査部23における検査の結果によって、冗長な機能であると判断されれば、削除される。なお、入力モデルM1および更新用モデルM2等のモデルは、本実施の形態では、フローチャートのような、処理フローレベルのモデルである。
 セキュリティデータベース22には、対策導入部21が更新用モデルM2に対してセキュリティ機能を導入する際に使用する情報が格納されている。
 ステップS103において、冗長性検査部23は、モデル検査を行う。具体的には、冗長性検査部23は、更新用モデルM2における冗長性の有無を確認する。
 ステップS104において、冗長性がなければ、ステップS105において、対策導入部21は、その時点の更新用モデルM2を出力モデルM3として出力する。そして、処理が終了する。
 ステップS104において、冗長性があれば、ステップS106において、冗長性検査部23は、冗長なセキュリティ機能のうち1つを削除する。そして、ステップS103において、冗長性検査部23は、再度モデル検査を行う。
 このように、冗長性検査部23は、更新用モデルM2に対してセキュリティ機能の冗長性を検証する。検証方法としては、本実施の形態では、同一箇所に複数のセキュリティ機能が連続して位置する場合に対処される脅威に重複はないか確認する方法が用いられる。なお、同一モデル中に同一のセキュリティ機能が必要以上に含まれていないか確認する方法、作成したモデルから形式言語への変換を行って冗長性を検証する方法、または、その他の方法が用いられてもよい。
 冗長性が完全になくなることを確認できるまで以上の処理が繰り返され、処理レベルにおいて脆弱性対策が施されたモデルが出力モデルM3として出力される。
 本実施の形態におけるセキュリティ機能の追加および削除の手順を、図4に示す処理モデル変化例を用いて説明する。
 ここでは、簡易なフローチャートを処理モデルとして作成および出力することを想定する。ユーザは、セキュリティ機能を考慮せずに入力モデルM1を作成する。ここで例として示している入力モデルM1は、簡易なフィールド機器の制御ソフトウェアのモデルである。この入力モデルM1は、制御ソフトウェアが機器を起動後、入力として停止コマンドを受信した場合、機器を停止させて終了するという処理モデルである。
 対策導入部21は、入力モデルM1と、図2のセキュリティデータベース22とを照合して、導入可能なすべてのセキュリティ機能を導入する。これにより、更新用モデルM2が得られる。冗長性検査部23は、更新用モデルM2に対してモデル検査を行う。冗長性検査部23は、冗長性があることを確認できたら、削除する候補を決定する。ここでは、冗長性の確認の方法として、同じ箇所に複数のセキュリティ機能が位置する場合の、対処される脅威の重複の有無を確認する方法が用いられる。
 セキュリティデータベース22では、導入箇所が「起動直後」および「入力直前」のように各処理について定められている。実際のモデルに機能を導入した場合、更新用モデルM2の起動直後から入力直前までの間のように、セキュリティデータベース22上では違う場所でも同じ箇所に2つ以上の機能が追加される場合がある。
 本例では、更新用モデルM2は、起動直後から入力直前までの間にセキュリティ処理P1およびセキュリティ処理P2、入力直後から分岐直前までの間にセキュリティ処理P3およびセキュリティ処理P4、分岐直後から停止直前までの間にセキュリティ処理P5およびセキュリティ処理P6を有している。セキュリティ処理P1、セキュリティ処理P2、セキュリティ処理P3、セキュリティ処理P4、セキュリティ処理P5およびセキュリティ処理P6は、それぞれセキュリティ1、セキュリティ2、セキュリティ3、セキュリティ4、セキュリティ5およびセキュリティ6の機能を持つ処理である。
 図2のセキュリティデータベース22によれば、脅威3の対策となる機能には、セキュリティ3、セキュリティ4およびセキュリティ6がある。本例では、それらに対応するセキュリティ処理P3、セキュリティ処理P4およびセキュリティ処理P6のうち、セキュリティ処理P3とセキュリティ処理P4とが同じ位置に連続している。そのため、一方が不要であると考えられる。冗長性検査部23は、更新用モデルM2からセキュリティ処理P4を削除する。これにより、出力モデルM3が得られる。
 なお、本例では、冗長性検査部23は、2つのセキュリティ機能を比較する際、セキュリティデータベース22における位置を比較して、下に位置する機能を削除するが、上に位置する機能を削除してもよい。あるいは、冗長性検査部23は、2つのセキュリティ機能を比較する際、更新用モデルM2における実行順序が先の機能を削除してもよいし、更新用モデルM2における実行順序が後の機能を削除してもよい。
 以上説明したように、対策導入部21には、プログラムの処理手順を定義する入力モデルM1が入力される。対策導入部21は、入力モデルM1が入力されると、セキュリティデータベース22を参照して、セキュリティデータベース22により定義された複数のセキュリティ処理の中から、入力モデルM1により定義された処理手順に導入する1つ以上のセキュリティ処理を選択する。対策導入部21は、選択したセキュリティ処理を導入した後のプログラムの処理手順を定義する出力モデルM3を出力する。「プログラム」は、本実施の形態ではフィールド機器の制御プログラムであるが、車載機器の制御プログラム等、任意の種類のプログラムでよい。
 本実施の形態では、「1つ以上のセキュリティ処理」は、セキュリティデータベース22により定義された導入箇所が入力モデルM1により定義された処理手順の中に存在するセキュリティ処理である。図4の例では、「1つ以上のセキュリティ処理」は、セキュリティ処理P1、セキュリティ処理P2、セキュリティ処理P3、セキュリティ処理P4、セキュリティ処理P5およびセキュリティ処理P6である。
 冗長性検査部23は、対策導入部21により選択されたセキュリティ処理の中に、プログラムの処理手順における導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれているかどうかを確認する。冗長性検査部23は、そのような2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理を、出力モデルM3により定義される処理手順への導入対象から除外する。冗長性検査部23は、本実施の形態では、「少なくとも1つのセキュリティ処理」として、「2つ以上のセキュリティ処理」のうち1つ以外のセキュリティ処理を導入対象から除外する。
 本実施の形態では、「2つ以上のセキュリティ処理」は、プログラムの処理手順の中で連続して実行され、かつ、セキュリティデータベース22により定義された脅威が一致するセキュリティ処理である。図4の例では、「2つ以上のセキュリティ処理」は、図2のセキュリティデータベース22で脅威3に対応するセキュリティ処理P3およびセキュリティ処理P4である。
 本実施の形態において、冗長性検査部23は、セキュリティデータベース22における「2つ以上のセキュリティ処理」の登録位置によって、「2つ以上のセキュリティ処理」のそれぞれを導入対象から除外するかどうかを決定する。図4の例では、冗長性検査部23は、セキュリティ処理P3およびセキュリティ処理P4のうち、図2のセキュリティデータベース22で下にあるセキュリティ処理P4を導入対象から除外している。
 なお、冗長性検査部23は、プログラムの処理手順における「2つ以上のセキュリティ処理」の実行順序によって、「2つ以上のセキュリティ処理」のそれぞれを導入対象から除外するかどうかを決定してもよい。図4の例では、冗長性検査部23は、セキュリティ処理P3およびセキュリティ処理P4のうち、後に実行されるセキュリティ処理P4を導入対象から除外していると考えてもよい。
 図5および図6を参照して、本実施の形態の変形例を説明する。
 図2のセキュリティデータベース22では、「起動直後」および「停止直前」のようにセキュリティ導入箇所が狭く定められているが、図5のセキュリティデータベース22では、セキュリティ3の導入箇所「起動以後~停止以前」のように、導入箇所を広く定めることができる。
 この変形例におけるセキュリティ機能の追加および削除の手順を、図6に示す処理モデル変化例を用いて説明する。
 図4の例と同じ入力モデルM1に対して機能を全箇所に導入すると、図6の更新用モデルM2が得られる。この更新用モデルM2は、起動直後から入力直前までの間にセキュリティ処理P1、セキュリティ処理P2およびセキュリティ処理P3a、入力直後から分岐直前までの間にセキュリティ処理P3bおよびセキュリティ処理P4、分岐直後から停止直前までの間にセキュリティ処理P3c、セキュリティ処理P5およびセキュリティ処理P6を有している。セキュリティ処理P3a、セキュリティ処理P3bおよびセキュリティ処理P3cは、いずれもセキュリティ3の機能を持つ処理である。セキュリティ処理P1、セキュリティ処理P2、セキュリティ処理P4、セキュリティ処理P5およびセキュリティ処理P6については、図4の例と同じ処理である。
 図5のセキュリティデータベース22によれば、脅威3の対策となる機能には、セキュリティ3、セキュリティ4およびセキュリティ6がある。この変形例では、それらに対応するセキュリティ処理P3a、セキュリティ処理P3b、セキュリティ処理P3c、セキュリティ処理P4およびセキュリティ処理P6のうち、セキュリティ処理P3bとセキュリティ処理P4とが同じ位置に連続している。そのため、一方が不要であると考えられる。冗長性検査部23は、更新用モデルM2からセキュリティ処理P4を削除する。また、セキュリティ処理P3cとセキュリティ処理P6とが同じ位置に連続している。そのため、一方が不要であると考えられる。冗長性検査部23は、更新用モデルM2からセキュリティ処理P6を削除する。これにより、図6の出力モデルM3が得られる。
 ***実施の形態の効果の説明***
 本実施の形態では、セキュリティデータベース22により定義された複数のセキュリティ処理の中から、導入する1つ以上のセキュリティ処理が選択される。選択したセキュリティ処理の中に、処理レベルでの導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理が導入対象から除外される。したがって、本実施の形態によれば、処理レベルでセキュリティ機能を効率的に導入することができる。
 本実施の形態では、入力モデルM1に対して、セキュリティデータベース22に基づいて導入可能なセキュリティ機能がすべて導入され、モデル検査を基に、セキュリティ機能の削除が繰り返される。本実施の形態によれば、脆弱性箇所を特定せずにセキュリティ機能を導入することで、処理フローのレベルにおいて適切なセキュリティ機能を重複なく適切な箇所に導入することができる。
 ***他の構成***
 本実施の形態では、対策導入部21および冗長性検査部23の機能がソフトウェアにより実現されるが、他の構成例として、対策導入部21および冗長性検査部23の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。すなわち、対策導入部21および冗長性検査部23の機能の一部が専用のハードウェアにより実現され、残りがソフトウェアにより実現されてもよい。
 専用のハードウェアは、例えば、単一回路、複合回路、プログラム化したプロセッサ、並列プログラム化したプロセッサ、ロジックIC、GA、FPGA、ASIC、または、これらのうちいくつか、もしくは、すべての組み合わせである。「IC」は、Integrated Circuitの略語である。「GA」は、Gate Arrayの略語である。「FPGA」は、Field-Programmable Gate Arrayの略語である。「ASIC」は、Application Specific Integrated Circuitの略語である。
 プロセッサ11および専用のハードウェアは、いずれも処理回路である。すなわち、対策導入部21および冗長性検査部23の機能がソフトウェアにより実現されるか、ソフトウェアとハードウェアとの組み合わせにより実現されるかに関わらず、対策導入部21および冗長性検査部23の動作は、処理回路により行われる。
 実施の形態2.
 本実施の形態について、主に実施の形態1との差異を、図7から図9を用いて説明する。
 ***構成の説明***
 本実施の形態に係るセキュリティ設計装置10の構成については、図1に示した実施の形態1のものと同様であるため、説明を説明する。
 図7に、セキュリティデータベース22の構成例を示す。
 セキュリティデータベース22は、実施の形態1と同じように、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義するデータベースである。本実施の形態では、各セキュリティ機能について、対処される脅威と、処理レベルにおける導入箇所との定義に加えて、優先順位の定義が保持されている。すなわち、本実施の形態では、セキュリティデータベース22は、複数のセキュリティ処理のうち少なくとも一部のセキュリティ処理について、優先順位を定義している。
 なお、図7では、自然言語による定義の例を記載しているが、プログラムまたはモデルで容易に解釈が可能な形式による定義が適用されてもよい。
 ***動作の説明***
 図8を参照して、本実施の形態に係るセキュリティ設計装置10の動作を説明する。セキュリティ設計装置10の動作は、本実施の形態に係るセキュリティ設計方法に相当する。
 ステップS201からステップS205の処理については、実施の形態1におけるステップS101からステップS105の処理と同じであるため、説明を省略する。
 ステップS204において、冗長性があり、ステップS206において、削除候補となるセキュリティ機能が1つのみであれば、ステップS207において、冗長性検査部23は、そのセキュリティ機能を削除する。そして、ステップS203において、冗長性検査部23は、再度モデル検査を行う。
 ステップS204において、冗長性があり、ステップS206において、削除候補となるセキュリティ機能が複数あれば、ステップS208において、冗長性検査部23は、優先順位の低い削除候補を選択する。ステップS207において、冗長性検査部23は、選択したセキュリティ機能を削除する。そして、ステップS203において、冗長性検査部23は、再度モデル検査を行う。
 冗長性が完全になくなることを確認できるまで以上の処理が繰り返され、処理レベルにおいて脆弱性対策が施されたモデルが出力モデルM3として出力される。
 本実施の形態におけるセキュリティ機能の追加および削除の手順を、図9に示す処理モデル変化例を用いて説明する。
 ここでは、図4の例と同じ入力モデルM1に対してセキュリティを導入したモデルを作成および出力することを想定する。
 対策導入部21は、入力モデルM1と、図7のセキュリティデータベース22とを照合して、導入可能なすべてのセキュリティ機能を導入する。これにより、更新用モデルM2が得られる。冗長性検査部23は、更新用モデルM2に対してモデル検査を行う。冗長性検査部23は、冗長性があることを確認できたら、削除する候補を決定する。ここでは、図4の例と同じように、冗長性の確認の方法として、同じ箇所に複数のセキュリティ機能が位置する場合の、対処される脅威の重複の有無を確認する方法が用いられる。
 本例では、図4の例と同じように、更新用モデルM2は、起動直後から入力直前までの間にセキュリティ処理P1およびセキュリティ処理P2、入力直後から分岐直前までの間にセキュリティ処理P3およびセキュリティ処理P4、分岐直後から停止直前までの間にセキュリティ処理P5およびセキュリティ処理P6を有している。セキュリティ処理P1、セキュリティ処理P2、セキュリティ処理P3、セキュリティ処理P4、セキュリティ処理P5およびセキュリティ処理P6は、それぞれセキュリティ1、セキュリティ2、セキュリティ3、セキュリティ4、セキュリティ5およびセキュリティ6の機能を持つ処理である。
 図7のセキュリティデータベース22によれば、脅威3の対策となる機能には、セキュリティ3、セキュリティ4およびセキュリティ6がある。本例では、それらに対応するセキュリティ処理P3、セキュリティ処理P4およびセキュリティ処理P6のうち、セキュリティ処理P3とセキュリティ処理P4とが同じ位置に連続している。そのため、一方が不要であると考えられる。図7のセキュリティデータベース22によれば、セキュリティ3およびセキュリティ4の優先順位は、それぞれ「2」および「1」であるため、セキュリティ処理P4のほうが優先順位は高い。よって、図4の例とは異なり、冗長性検査部23は、更新用モデルM2からセキュリティ処理P3を削除する。これにより、出力モデルM3が得られる。
 このように、同一の脅威に対処できる機能がセキュリティデータベース22に複数保持されていて、それらの機能が処理上で同じ位置に追加された場合、図4の例では、セキュリティデータベース22において上側に位置するセキュリティ機能を残し、他が削除されるが、本例では、優先順位が低いセキュリティ機能が削除される。
 以上説明したように、本実施の形態において、冗長性検査部23は、セキュリティデータベース22により定義された優先順位によって、「2つ以上のセキュリティ処理」のそれぞれを導入対象から除外するかどうかを決定する。図9の例では、冗長性検査部23は、セキュリティ処理P3およびセキュリティ処理P4のうち、図7のセキュリティデータベース22で優先順位が低いセキュリティ処理P3を導入対象から除外している。
 ***実施の形態の効果の説明***
 本実施の形態では、入力モデルM1に対して、セキュリティデータベース22に基づいて導入可能なセキュリティ機能がすべて導入され、モデル検査および優先順位を基に、セキュリティ機能の削除が繰り返される。本実施の形態によれば、実施の形態1と同様に、脆弱性箇所を特定せずにセキュリティ機能を導入することで、処理フローのレベルにおいて適切なセキュリティ機能を重複なく適切な箇所に導入することができる。
 実施の形態3.
 本実施の形態について、主に実施の形態1との差異を、図10から図13を用いて説明する。
 ***構成の説明***
 図10を参照して、本実施の形態に係るセキュリティ設計装置10の構成を説明する。
 セキュリティ設計装置10は、対策導入部21と、セキュリティデータベース22と、冗長性検査部23とに加えて、評価部24を備える。対策導入部21、冗長性検査部23および評価部24の機能は、ソフトウェアにより実現される。
 図11に、セキュリティデータベース22の構成例を示す。
 セキュリティデータベース22は、実施の形態1と同じように、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義するデータベースである。本実施の形態では、各セキュリティ機能について、対処される脅威と、処理レベルにおける導入箇所との定義に加えて、機能導入に要するコストの定義が保持されている。すなわち、本実施の形態では、セキュリティデータベース22は、複数のセキュリティ処理のそれぞれについて、コストを定義している。コストの例としては、暗号化の鍵長、および、セキュリティ機能の実行に要する時間が挙げられる。セキュリティデータベース22において、複数種類のコストの定義が保持されていてもよい。
 なお、図11では、自然言語による定義の例を記載しているが、プログラムまたはモデルで容易に解釈が可能な形式による定義が適用されてもよい。
 ***動作の説明***
 図12を参照して、本実施の形態に係るセキュリティ設計装置10の動作を説明する。セキュリティ設計装置10の動作は、本実施の形態に係るセキュリティ設計方法に相当する。
 ステップS300において、評価部24は、パフォーマンスおよびセキュリティ等、設計対象のモデルにおけるユーザの要求に基づいて、コストから算出する評価値を設定および定義し、セキュリティデータベース22に登録する。パフォーマンスとは、全体の処理速度のことである。
 ステップS301からステップS305の処理については、実施の形態1におけるステップS101からステップS105の処理と同じであるため、説明を省略する。
 ステップS304において、冗長性があり、ステップS306において、削除候補となるセキュリティ機能が1つのみであれば、ステップS307において、冗長性検査部23は、そのセキュリティ機能を削除する。そして、ステップS303において、冗長性検査部23は、再度モデル検査を行う。
 ステップS304において、冗長性があり、ステップS306において、削除候補となるセキュリティ機能が複数あれば、ステップS308において、評価部24は、各候補を削除した場合の評価値を算出する。具体的には、評価部24は、セキュリティデータベース22に保持されているコストの定義を基に、セキュリティ機能が導入されたモデルの評価値を算出する。評価の例としては、パフォーマンスおよびセキュリティの強度の確認等が挙げられる。評価値は、コスト同士の単純な加算値または乗算値でもよいし、ユーザが独自に定義した関数により求められる値でもよい。冗長性検査部23は、評価部24において算出された、モデル同士の評価値を比較し、評価値の低い削除候補を選択する。ステップS207において、冗長性検査部23は、選択したセキュリティ機能を削除する。そして、ステップS203において、冗長性検査部23は、再度モデル検査を行う。
 冗長性が完全になくなることを確認できるまで以上の処理が繰り返され、処理レベルにおいて脆弱性対策が施されたモデルが出力モデルM3として出力される。
 本実施の形態におけるセキュリティ機能の追加および削除の手順を、図13に示す処理モデル変化例を用いて説明する。
 ここでは、図4の例と同じ入力モデルM1に対してセキュリティを導入したモデルを作成および出力することを想定する。
 対策導入部21は、入力モデルM1と、図11のセキュリティデータベース22とを照合して、導入可能なすべてのセキュリティ機能を導入する。これにより、更新用モデルM2が得られる。冗長性検査部23は、更新用モデルM2に対してモデル検査を行う。冗長性検査部23は、冗長性があることを確認できたら、削除する候補を決定する。ここでは、図4の例と同じように、冗長性の確認の方法として、同じ箇所に複数のセキュリティ機能が位置する場合の、対処される脅威の重複の有無を確認する方法が用いられる。
 本例では、図4の例と同じように、更新用モデルM2は、起動直後から入力直前までの間にセキュリティ処理P1およびセキュリティ処理P2、入力直後から分岐直前までの間にセキュリティ処理P3およびセキュリティ処理P4、分岐直後から停止直前までの間にセキュリティ処理P5およびセキュリティ処理P6を有している。セキュリティ処理P1、セキュリティ処理P2、セキュリティ処理P3、セキュリティ処理P4、セキュリティ処理P5およびセキュリティ処理P6は、それぞれセキュリティ1、セキュリティ2、セキュリティ3、セキュリティ4、セキュリティ5およびセキュリティ6の機能を持つ処理である。
 図11のセキュリティデータベース22によれば、脅威3の対策となる機能には、セキュリティ3、セキュリティ4およびセキュリティ6がある。本例では、それらに対応するセキュリティ処理P3、セキュリティ処理P4およびセキュリティ処理P6のうち、セキュリティ処理P3とセキュリティ処理P4とが同じ位置に連続している。そのため、一方が不要であると考えられる。よって、得られるモデルとしては、セキュリティ処理P4を削除した出力モデルM3aと、セキュリティ処理P3を削除した出力モデルM3bとが考えられる。このように削除候補が複数ある場合、評価部24は、それぞれの候補に対してユーザが定義した評価値を算出する。冗長性検査部23は、評価値が高いモデルを採用する。ユーザが定義した評価値が、モデルが有するセキュリティ機能のコストの総和の逆数であれば、出力モデルM3aの評価値は1/(C1+C2+C3+C5+C6)であり、出力モデルM3bの評価値は1/(C1+C2+C4+C5+C6)となる。そのため、C3とC4との大小で削除する機能が決まる。C3<C4であれば、冗長性検査部23は、更新用モデルM2からセキュリティ処理P4を削除する。これにより、出力モデルM3aが得られる。C3>C4であれば、冗長性検査部23は、更新用モデルM2からセキュリティ処理P3を削除する。これにより、出力モデルM3bが得られる。C3=C4であれば、冗長性検査部23は、更新用モデルM2からセキュリティ処理P4を削除してもよいし、セキュリティ処理P3を削除してもよい。このように複数の候補で評価値が同じ値になった場合は、実施の形態1と同様に、セキュリティデータベース22上の位置を基に削除する機能を決めてもよいし、実施の形態2と同様に、優先順位を基に削除する機能を決めてもよい。
 以上説明したように、本実施の形態において、冗長性検査部23は、セキュリティデータベース22により定義されたコストによって、「2つ以上のセキュリティ処理」のそれぞれを導入対象から除外するかどうかを決定する。図13の例では、冗長性検査部23は、セキュリティ処理P3およびセキュリティ処理P4のうち、図11のセキュリティデータベース22でコストが低いほうのセキュリティ処理を導入対象から除外している。
 ***実施の形態の効果の説明***
 本実施の形態では、入力モデルM1に対して、セキュリティデータベース22に基づいて導入可能なセキュリティ機能がすべて導入され、モデル検査およびコストによるモデル評価を基に、セキュリティ機能の削除が繰り返される。本実施の形態によれば、セキュリティおよびパフォーマンスの面でユーザの要求を考慮しながら、セキュリティ機能を導入できる。脆弱性箇所を特定せずにセキュリティ機能を導入し、モデルの検証により脆弱性の有無を確認するとともに、ユーザの要求を確認することで、処理フローのレベルにおいて適切なセキュリティ機能を重複なく適切な箇所に導入することができる。
 ***他の構成***
 本実施の形態では、実施の形態1と同じように、対策導入部21、冗長性検査部23および評価部24の機能がソフトウェアにより実現されるが、実施の形態1の他の構成例と同じように、対策導入部21、冗長性検査部23および評価部24の機能がソフトウェアとハードウェアとの組み合わせにより実現されてもよい。
 実施の形態4.
 本実施の形態について、主に実施の形態1との差異を、図14から図20を用いて説明する。
 本実施の形態では、モデルに使用される情報資産に基づいてモデル内の処理をグループ化し、各グループに含まれる情報資産の重要度に応じたセキュリティ機能をセキュリティDBに基づいて導入する。
 ここで、情報資産とは、モデルを構成する要素である。ソフトウェア設計のためのモデルの場合、情報資産とは、モデル内で使用されている変数、定数、処理、ルーチン、機能、または、関数等である。
 また、情報資産の重要度とは、モデルにおける情報資産の価値の度合いである。また、重要度とは、「セキュリティ強度」「機密性」「完全性」「可用性」「脆弱性」のような特性または属性でもよい。また、重要度とは、パフォーマンス(全体の処理速度)、実行頻度、リソース(CPU・メモリ等)の使用頻度、リソースの使用時間、リソースの使用量のような特性または属性でもよい。
 本実施の形態では、セキュリティDBは複数存在し、各セキュリティDBは、セキュリティの強度によって異なるセキュリティ機能とその導入のルールを保持している。
 本実施の形態では、脅威から防ぐ情報資産の重要度によってセキュリティDB22を使い分ける。
 ***構成の説明***
 図14は、この発明の実施の形態に係るセキュリティ設計装置10を示す構成図である。
 図14のセキュリティ設計装置10は、実施の形態1と同様の対策導入部21、セキュリティDB22、および、冗長性検査部23に加えて、処理分類部25から構成される。
 処理分類部25は、モデル内で扱われる情報資産重要度情報L1を入力する。情報資産重要度情報L1は、モデル内で扱われる情報資産の重要度を示す情報である。
 処理分類部25は、情報資産重要度情報L1を参照して、モデル内で使用される情報資産に基づいて、モデル内の処理をグループ化する。
 セキュリティDB22は、情報資産の重要度に応じたセキュリティ処理を定義している。
 対策導入部21は、複数のセキュリティ処理の中から、処理分類部25によりグループ化された処理手順に対して導入するセキュリティ処理を選択し、グループ化された処理手順に対して選択したセキュリティ処理を導入する。
 図15のセキュリティDB22Aは、重要度が高い情報資産用のセキュリティDBの具体例である。
 図16のセキュリティDB22Bは、重要度が低い情報資産用のセキュリティDBの具体例である。
 重要度が高い情報資産に適用するセキュリティDB22Aは、強いセキュリティ機能が多く含まれている。
 逆に、重要度が低い情報資産に適用するセキュリティDB22Bは、比較的弱いセキュリティ機能が含まれている。
 複数のセキュリティDB同士で同じ機能を重複して保持してもよい。
 処理分類部25に対する入力として、入力モデルM1に加えて、情報資産重要度情報L1を入力する。
 情報資産重要度情報L1は、例えば「コマンドA:重要度高」「コマンドB:重要度低」等と、入力モデルM1に含まれる情報資産とその重要度が示されている。
 情報の重要度を「機密性」「完全性」「可用性」のような複数の特性に分類し、それぞれに対応したセキュリティDBを用意してもよい。また、事前にモデル内の脆弱性情報を入手し、情報資産の重要度の判断に用いてもよい。
 処理分類部25は、入力モデル内で同じ情報資産が使用されている処理を抽出し、グループ化する。
 グループ化を実現する方法の例として、同じ変数が使われている処理を抽出する方法、または、データフローを利用して追跡する方法が挙げられる。グループ化した処理は、実施の形態1等におけるモデルと同様に扱うことができ、セキュリティDB22と照合して後段の対策導入部21と冗長性検査部23に入力される。
 ただし、本実施の形態では各情報資産の重要度に応じたセキュリティ機能を導入するため、実施の形態1~3では存在の前提としていた冗長性が減少していること、または、冗長性が存在しないことも考えられる。したがって、冗長性検査部23が動作しないまたは不要な可能性もある。
 ***概要動作説明***
 図17のセキュリティ設計装置10の概要動作のフローチャートを用いて、実施の形態4におけるセキュリティ機能の追加の手順について説明する。
 ユーザはモデルを用いてセキュリティを考慮せずにソフトウェア設計を行う。
 ステップS401において、作成した入力モデルM1および情報資産重要度情報L1を、本セキュリティ設計装置10に入力する。すなわち、ユーザは、開発対象の制御モデルに加えて、モデル内で扱われる情報資産の重要度情報を入力する。
 ステップS402において、セキュリティ設計装置10は、モデルを処理分類部25に入力する。処理分類部25は、モデル内に含まれる処理を、モデル内で使用されている情報資産に基づいて、グループ化してグループ化したモデルを更新用モデルM2として出力する。
 ステップS403において、対策導入部21は、セキュリティDB22を基に、更新用モデルM2の各グループに対して導入可能なセキュリティ機能を全箇所に追加する。
 そして、ステップS404において、冗長性検査部23は、モデル検査を行い、更新用モデルM2における冗長性の有無を確認する。
 ステップS405において、更新用モデルM2に冗長性がないと判断された場合、その時点の更新用モデルM2を出力モデルM3として出力し、ステップS406に行き処理を終了する。
 ステップS405において、更新用モデルM2に冗長性があると判断された場合、ステップS407において、対策導入部21は、更新用モデルM2の冗長なセキュリティ機能のうち1つを削除し、再度モデル検査を行う。
 セキュリティ設計装置10は、冗長性が完全になくなることを確認できるまで以上の処理を繰り返し、処理レベルにおいて脆弱性対策が施されたモデルを出力する。
 ***DBとモデル例による動作説明***
 図18に示すグループ化によるモデル変化例を用いて、セキュリティ機能の追加の手順を説明する。
 ここでは、簡易なフローチャートを処理モデルとして入力して出力することを想定する。
 ユーザは、セキュリティ機能を考慮せずにモデルM410を作成する。ここで例として示しているモデルM410は、フィールド機器の制御ソフトウェアを想定し、外部から複数のコマンド、すなわちコマンドAとコマンドBをそれぞれ受信し、さらに外部へ各コマンドを送信して終了するという処理モデルである。ただし、コマンドAは重要度が高く、コマンドBは重要度が低いものとする。
 情報資産重要度情報L1は、コマンドAは重要度が高く、コマンドBは重要度が低いことを示す情報である。
 ユーザは、処理モデルM410および情報資産重要度情報L1を入力する。
 処理分類部25は、各処理で使用される情報資産に基づいて、各処理をグループ化する。
 モデルM410にはコマンドAが使用される処理と、コマンドBが使用される処理があるため、各処理を二つのグループに分類することができる。
 図18に示すように、処理分類部25は、モデルM410を、コマンドAが使用されるグループG421とコマンドBが使用されるグループG422という二つのグループに分類して、モデルM420として出力する。
 続いて、対策導入部21は、グループ化済みのモデルM420に対して図15のセキュリティDB22Aと図16のセキュリティDB22Bを照合して、各グループに導入可能なセキュリティ機能を導入する。
 対策導入部21は、グループG421にセキュリティDB22Aのセキュリティ機能を導入し、グループG422にセキュリティDB22Bのセキュリティ機能を導入し、モデルM430として出力する。
 この後、実施の形態1と同様に、必要に応じてモデルM430に対してモデル検査を行い、冗長な機能を削除する。削除後、再度モデル検査を行い、冗長性の有無を確認する。
 ***実施の形態の効果の説明***
 本実施の形態によれば、ユーザが定めた情報資産の重要度に応じたセキュリティ機能を導入できる。
 本実施の形態によれば、脆弱性箇所を特定せずにセキュリティ機能を導入し、モデルの検証により脆弱性の有無を確認するとともに、情報資産の重要度を確認することで、処理レベルにおいてセキュリティ機能を重複なく適切な個数・箇所に導入できる。
 ***他の動作説明***
 先述の例では全く同じ情報資産が使われていることに基づいて処理を抽出・グループ化したが、処理の抽出・グループ化には、データフローを利用する方法等、他の方法も考えられる。
 例えば、図19に示すグループ化によるモデル変化例では、情報資産の処理内容に着目する。入力するモデルMa410では、先述と同様にコマンドA(重要度:高)とコマンドB(重要度:低)を使用しているが、途中の処理Ma413でコマンドを加算している。
 処理分類部25は、「C=A+B」という加算処理Ma413と、加算処理以後の「コマンドC送信」という送信処理Ma414との重要度を高く扱う。
 処理分類部25は、モデルMa420を、グループGa421とグループGa422という二つのグループに分類して、モデルMa420として出力する。
 このように重要度が異なる情報資産同士の演算・演算結果が含まれる場合は、それらを重要度の高い情報資産のグループへ含める。
 そして、対策導入部21は、先述と同様に図15のセキュリティDB22Aと図16のセキュリティDB22Bを照合して、情報資産毎のセキュリティ機能が含まれたモデルMa430を出力する。
 ***他の動作説明***
 図20に示すグループ化によるモデル変化例では、情報資産の使用方法に着目する。
 入力するモデルMb410では、先述と同様にコマンドA(重要度:高)とコマンドB(重要度:低)を使用しているが、途中の処理Mb413でコマンドAを分岐の制御変数として使用している。
 処理分類部25は、「コマンドA=?」という分岐処理Mb413と、分岐処理以後の送信処理Mb414、Mb415との重要度を高く扱う。
 このように重要度が高い情報資産を制御変数として用いている場合は、その結果行われる後段の処理も重要度が高いグループに含める(モデルMb420のグループGb421)。
 そして、対策導入部21は、先述と同様に図15のセキュリティDB22Aと図16のセキュリティDB22Bを照合して、情報資産毎のセキュリティ機能が含まれたモデルMb430を出力する。
 実施の形態5.
 本実施の形態について、主に実施の形態4との差異を、図21から図25を用いて説明する。
 本実施の形態では、セキュリティ機能を有しないモデルに対して、モデルで使用される情報資産に基づいてモデル内の処理をグループ化し、セキュリティDBに基づいてグループに対して導入可能なセキュリティ機能を全て導入する。
 本実施の形態では、モデル検査およびコストによるモデル内のグループ評価を基に、セキュリティ機能の削除または交換を繰り返すことを特徴とする。
 ***構成の説明***
 図21は、この発明の実施の形態に係るセキュリティ設計装置10を示す構成図である。
 図21のセキュリティ設計装置10は、実施の形態4と同様の対策導入部21、セキュリティDB22、冗長性検査部23、および、処理分類部25に加え、グループ評価部26から構成される。
 グループ評価部26は、セキュリティDBにより定義されたコストに基づいて、グループ化された処理手順の中のセキュリティ処理の評価値を求め、評価値に基づいて、グループ化された処理手順の中のセキュリティ処理を導入対象から除外するかどうかを決定する。
 セキュリティDB22は、実施の形態4と同様に対策導入部21において更新用モデルM2に対してセキュリティを導入する際に使用する情報を格納している。
 図22のセキュリティDB22Aと、図23のセキュリティDB22Bは、図21のセキュリティDB22の構成要素例である。
 図22のセキュリティDB22Aは、重要度が高い情報資産用のセキュリティDBの具体例である。
 図23のセキュリティDB22Bは、重要度が低い情報資産用のセキュリティDBの具体例である。
 セキュリティDB22AとセキュリティDB22Bには、実施の形態4と同様のセキュリティ機能導入のルールに加え、機能導入に要するコストCが保持されている。
 コストCの例としては、暗号化の鍵長、セキュリティ機能実行に要する時間等が考えられる。1つのDB内に、複数種類のコストを保持してもよい。
 グループ評価部26は、セキュリティDB22に保持されているコストCを基に、セキュリティ機能が導入されたモデルのグループに対して、評価値を算出する。
 評価の目的としては、パフォーマンス(全体の処理速度)やセキュリティの強度、CPU・メモリ等のリソース制限の考慮等が挙げられる。評価値はコスト同士の単純な加算または乗算でもよいし、ユーザが独自に関数を定義してもよい。
 また、グループ評価部26において、モデルの評価値を算出し、モデルがユーザの要求を満たすモデルかどうかを確認する。要求を満たさない場合は、対策導入部21でセキュリティ機能を削除または他の機能に交換する。または、ユーザに警告を提示する方法も考えられる。
 ただし、本実施の形態では実施の形態4と同様に各情報資産の重要度に応じたセキュリティ機能を導入するため、実施の形態1~3では存在の前提としていた冗長性が減少または存在しないことも考えられる。したがって、冗長性検査部23が動作しないまたは不要な可能性もある。
 ***概要動作説明***
 図24のセキュリティ設計装置10の概要動作のフローチャートを用いて、実施の形態5におけるセキュリティ機能の導入の手順について説明する。
 はじめに、ステップS500において、パフォーマンス(全体の処理速度)やセキュリティ強度、CPU・メモリ等のリソース制限等、設計対象のモデルにおけるユーザの要求に基づいて、セキュリティ処理の処理時間の評価基準を設定し定義しておく。
 ステップS501において、ユーザはモデルを用いてセキュリティを考慮せずにソフトウェア設計を行い、作成した入力モデルM1および情報資産重要度情報L1を、本セキュリティ設計装置10に入力する。
 ステップS502において、セキュリティ設計装置10では、入力モデルM1を処理分類部25に入力する。処理分類部25は、モデル内に含まれる処理を、使用される情報資産に基づいてグループ化して、グループ化したモデルを更新用モデルM2として出力する。
 ステップS503において、対策導入部21は、セキュリティDB22を基に、更新用モデルM2に対して導入可能なセキュリティ機能を全箇所に追加する。
 ステップS504において、冗長性検査部23においてモデル検査を行い、更新用モデルM2における冗長性の有無を確認する。
 ステップS504において、更新用モデルM2に冗長性があると判断された場合、ステップS505において、対策導入部21は、冗長なセキュリティ機能のうち1つを削除し、再度モデル検査を行う。
 ステップS504において、更新用モデルM2に冗長性がないと判断された場合、ステップS507において、グループ評価部26は、その時点の更新用モデルM2の各グループにおける評価値を算出する。
 ステップS508において、評価値が基準を満たしていることを確認できれば、対策導入部21は、その時点の更新用モデルM2を出力モデルM3として、ステップS509に行き処理を終了する。
 評価値が基準を満たしていなければ、ステップS506において、対策導入部21は、その時点の更新用モデルM2内のセキュリティ機能を1つ削除するか、またはコスト値の低いセキュリティ機能に交換し、冗長性検査部23が、再度冗長性検査を行う。
 セキュリティ設計装置10は、冗長性がないことおよび評価値が基準を満たしていることを確認できるまで、以上の処理を繰り返し、処理レベルにおいて情報資産毎にセキュリティ機能が施されたモデルを出力する。
 ***DBとモデル例による動作説明***
 図25に示すグループ化によるモデル変化例を用いて、実施の形態5におけるセキュリティ機能の追加の手順を説明する。
 ここでは、簡易なフローチャートを処理モデルとして入力して出力する。
 ユーザは、セキュリティ機能を考慮せずにモデルM510を作成する。ここで例として示しているモデルM510は、フィールド機器の制御ソフトウェアを想定し、外部から複数のコマンド、すなわちコマンドAとコマンドBをそれぞれ受信し、さらに外部へ各コマンドを送信して終了するという処理モデルである。
 ただし、コマンドAは重要度が高く、コマンドBは重要度が低いものとする。
 ユーザは、はじめにコマンドAに関する評価基準、コマンドBに関する評価基準を定める。
 例えば、各コマンドに対するセキュリティ処理の処理時間を評価することを想定する。
 ユーザは、セキュリティ処理の処理時間の評価基準としてコマンドAに関する評価基準CA0とコマンドBに関する評価基準CB0を定め、リアルタイム性の考慮により、各コマンドのセキュリティ処理の処理時間がこの評価基準を超過してはいけないとする。
 ユーザは、処理モデルM510を入力モデルM1として入力する。
 処理分類部25は、各処理で使用される情報資産に基づいて、各処理をグループ化する。
 モデルM510にはコマンドAが使用される処理と、コマンドBが使用される処理があるため、処理分類部25は、各処理を二つのグループに分類することができる(図25のモデルM520のグループG521とグループG522)。
 続いて、対策導入部21は、グループ化済みのモデルM520に対して、図22のセキュリティDB22Aと図23のセキュリティDB22Bを照合して、各グループに導入可能なセキュリティ機能を導入する。
 対策導入部21は、グループG521にセキュリティDB22Aのセキュリティ機能を導入し、グループG522にセキュリティDB22Bのセキュリティ機能を導入し、モデルM530として出力する。
 冗長性検査部23においてモデル検査を行い、更新用モデルM2における冗長性の有無を確認する。
 更新用モデルM2に冗長性があると判断された場合、対策導入部21は、冗長なセキュリティ機能のうち1つを削除し、再度モデル検査を行う。
 更新用モデルM2に冗長性がないと判断された場合、グループ評価部26は、その時点の更新用モデルM2の各グループにおける評価値を算出する。
 グループ評価部26は、グループG531とグループG532の評価値を求める。
 例えば、グループ評価部26は、単純にコスト値を加算し、グループG531の評価値C=C+C+C、グループG532の評価値C=Cが得られる。
 グループ評価部26は、評価値と評価基準を比較し、C>CA0およびC<CB0となったとする。
 Cは基準CA0を超過してしまったので、グループG531のセキュリティ機能をいずれか1つ取り除くまたは他の処理と交換するという処理が必要となる。
 グループ評価部26は、取り除くまたは他の処理と交換するセキュリティ機能を決定して対策導入部21に指示する。
 図25では、対策導入部21が、改竄検知処理M541を取り除くことにより、C<CA0を満足させ、モデルM540を得た例を示している。
 グループ評価部26がグループの中からどのセキュリティ機能を取り除くまたは交換するかという判断は、セキュリティ機能の優先順位を利用してもよいし、セキュリティ機能のコスト値の大小等を利用してもよい。
 また、グループ評価部26が、セキュリティ機能を自動的に削除したり、セキュリティ機能を自動的に交換するのではなく、グループ評価部26が削除警告または選択肢をユーザに提示するという形でもよい。
 更新用モデルM2に冗長性がないことおよび評価値が基準を満たしていることを確認できるまで、以上の処理を繰り返す。
 グループ評価部26により全グループの評価値が基準を満たしていることを確認できれば、対策導入部21は、その時点の更新用モデルM2を出力モデルM3として出力する。
 ***実施の形態の効果の説明***
 本実施の形態によれば、ユーザが定めた情報資産の重要度に応じたセキュリティ機能を導入することができる。
 本実施の形態によれば、グループ評価部26を設けたので、システムのパフォーマンス(全体の処理速度)、セキュリティ強度、ハードウェアリソースの制限等を考慮してセキュリティ機能を導入することができる。
 ***他の実施の形態***
 前述した実施の形態の一部または全部を他の実施の形態と組み合わせてもよい。
 前述した実施の形態の一部または全部の機能が、ソフトウェアのみ、ハードウェアのみ、または、ソフトウェアとハードウェアとの組み合わせにより実現されてもよい。
 10 セキュリティ設計装置、11 プロセッサ、12 メモリ、13 通信デバイス、14 入力機器、15 ディスプレイ、21 対策導入部、22,22A,22B セキュリティデータベース、23 冗長性検査部、24 評価部、25 処理分類部、26 グループ評価部、M1 入力モデル、M2 更新用モデル、M3 出力モデル、M3a 出力モデル、M3b 出力モデル、P1 セキュリティ処理、P2 セキュリティ処理、P3 セキュリティ処理、P3a セキュリティ処理、P3b セキュリティ処理、P3c セキュリティ処理、P4 セキュリティ処理、P5 セキュリティ処理、P6 セキュリティ処理。

Claims (11)

  1.  プログラムの処理手順を定義する入力モデルが入力されると、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義するセキュリティデータベースを参照して、前記複数のセキュリティ処理の中から、前記入力モデルにより定義された処理手順に導入する1つ以上のセキュリティ処理を選択し、選択したセキュリティ処理を導入した後の前記プログラムの処理手順を定義する出力モデルを出力する対策導入部と、
     前記対策導入部により選択されたセキュリティ処理の中に、前記プログラムの処理手順における導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理を、前記出力モデルにより定義される処理手順への導入対象から除外する冗長性検査部と
    を備えるセキュリティ設計装置。
  2.  前記冗長性検査部は、前記少なくとも1つのセキュリティ処理として、前記2つ以上のセキュリティ処理のうち1つ以外のセキュリティ処理を導入対象から除外する請求項1に記載のセキュリティ設計装置。
  3.  前記セキュリティデータベースは、前記複数のセキュリティ処理のそれぞれについて、導入箇所と、その導入箇所に導入されたセキュリティ処理によって対処される脅威とを定義し、
     前記1つ以上のセキュリティ処理は、前記セキュリティデータベースにより定義された導入箇所が前記入力モデルにより定義された処理手順の中に存在するセキュリティ処理であり、
     前記2つ以上のセキュリティ処理は、前記プログラムの処理手順の中で連続して実行され、かつ、前記セキュリティデータベースにより定義された脅威が一致するセキュリティ処理である請求項1または2に記載のセキュリティ設計装置。
  4.  前記冗長性検査部は、前記セキュリティデータベースにおける前記2つ以上のセキュリティ処理の登録位置によって、前記2つ以上のセキュリティ処理のそれぞれを導入対象から除外するかどうかを決定する請求項1から3のいずれか1項に記載のセキュリティ設計装置。
  5.  前記セキュリティデータベースは、前記複数のセキュリティ処理のうち少なくとも一部のセキュリティ処理について、優先順位を定義し、
     前記冗長性検査部は、前記セキュリティデータベースにより定義された優先順位によって、前記2つ以上のセキュリティ処理のそれぞれを導入対象から除外するかどうかを決定する請求項1から3のいずれか1項に記載のセキュリティ設計装置。
  6.  前記セキュリティデータベースは、前記複数のセキュリティ処理のそれぞれについて、コストを定義し、
     前記冗長性検査部は、前記セキュリティデータベースにより定義されたコストによって、前記2つ以上のセキュリティ処理のそれぞれを導入対象から除外するかどうかを決定する請求項1から3のいずれか1項に記載のセキュリティ設計装置。
  7.  前記入力モデル内で使用される情報資産に基づいて前記入力モデル内の処理をグループ化する処理分類部を備え、
     前記対策導入部は、前記複数のセキュリティ処理の中から、グループ化された処理手順に対して導入するセキュリティ処理を選択し、グループ化された処理手順に対して選択したセキュリティ処理を導入する請求項1から6のいずれか1項に記載のセキュリティ設計装置。
  8.  前記処理分類部は、前記入力モデル内で扱われる情報資産の重要度情報を入力し、情報資産の重要度情報に基づいて、前記入力モデル内の処理をグループ化する請求項7に記載のセキュリティ設計装置。
  9.  前記セキュリティデータベースは、前記複数のセキュリティ処理のそれぞれについて、コストを定義し、
     前記セキュリティデータベースにより定義されたコストに基づいて、グループ化された処理手順の中のセキュリティ処理の評価値を求め、前記評価値に基づいて、グループ化された処理手順の中のセキュリティ処理を導入対象から除外するかどうかを決定するグループ評価部を備えた請求項7または8に記載のセキュリティ設計装置。
  10.  対策導入部は、プログラムの処理手順を定義する入力モデルが入力されると、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義するセキュリティデータベースを参照して、前記複数のセキュリティ処理の中から、前記入力モデルにより定義された処理手順に導入する1つ以上のセキュリティ処理を選択し、選択したセキュリティ処理を導入した後の前記プログラムの処理手順を定義する出力モデルを出力し、
     冗長性検査部は、前記対策導入部により選択されたセキュリティ処理の中に、前記プログラムの処理手順における導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理を、前記出力モデルにより定義される処理手順への導入対象から除外するセキュリティ設計方法。
  11.  コンピュータに、
     プログラムの処理手順を定義する入力モデルが入力されると、それぞれ脅威に対処するために実行される複数のセキュリティ処理を定義するセキュリティデータベースを参照して、前記複数のセキュリティ処理の中から、前記入力モデルにより定義された処理手順に導入する1つ以上のセキュリティ処理を選択し、選択したセキュリティ処理を導入した後の前記プログラムの処理手順を定義する出力モデルを出力する対策導入処理と、
     前記対策導入処理により選択されたセキュリティ処理の中に、前記プログラムの処理手順における導入箇所が重複し、かつ、同じ脅威に対処するために実行される2つ以上のセキュリティ処理が含まれていれば、それら2つ以上のセキュリティ処理のうち少なくとも1つのセキュリティ処理を、前記出力モデルにより定義される処理手順への導入対象から除外する冗長性検査処理と
    を実行させるセキュリティ設計プログラム。
PCT/JP2018/041818 2018-01-17 2018-11-12 セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム WO2019142469A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2019538449A JP6632777B2 (ja) 2018-01-17 2018-11-12 セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム
TW108101124A TW201933165A (zh) 2018-01-17 2019-01-11 安全設計裝置、安全設計方法及安全設計程式產品

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JPPCT/JP2018/001229 2018-01-17
PCT/JP2018/001229 WO2019142267A1 (ja) 2018-01-17 2018-01-17 セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム

Publications (1)

Publication Number Publication Date
WO2019142469A1 true WO2019142469A1 (ja) 2019-07-25

Family

ID=67301618

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2018/001229 WO2019142267A1 (ja) 2018-01-17 2018-01-17 セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム
PCT/JP2018/041818 WO2019142469A1 (ja) 2018-01-17 2018-11-12 セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/001229 WO2019142267A1 (ja) 2018-01-17 2018-01-17 セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム

Country Status (3)

Country Link
JP (1) JP6632777B2 (ja)
TW (1) TW201933165A (ja)
WO (2) WO2019142267A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021157073A1 (ja) * 2020-02-07 2021-08-12 三菱電機株式会社 情報処理装置、情報処理方法および情報処理プログラム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7272940B2 (ja) 2019-12-06 2023-05-12 株式会社日立製作所 セキュリティリスク軽減方法及びシステム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11134180A (ja) * 1997-10-27 1999-05-21 Nec Corp 状態遷移図変換装置
US20110302566A1 (en) * 2010-06-03 2011-12-08 International Business Machines Corporation Fixing security vulnerability in a source code
JP2013134573A (ja) * 2011-12-26 2013-07-08 Nec Corp ソフトウェア修正装置、ソフトウェア修正システム、ソフトウェア修正方法、及び、ソフトウェア修正プログラム
US9098292B1 (en) * 2014-04-29 2015-08-04 The Mathworks, Inc. Automatic generation of an optimized arrangement for a model and optimized code based on the model
JP2017068825A (ja) * 2015-09-29 2017-04-06 パナソニックIpマネジメント株式会社 ソフトウェア開発システムおよびプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63155329A (ja) * 1986-12-19 1988-06-28 Fujitsu Ltd タスクモジユ−ルの冗長プログラム削減装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11134180A (ja) * 1997-10-27 1999-05-21 Nec Corp 状態遷移図変換装置
US20110302566A1 (en) * 2010-06-03 2011-12-08 International Business Machines Corporation Fixing security vulnerability in a source code
JP2013134573A (ja) * 2011-12-26 2013-07-08 Nec Corp ソフトウェア修正装置、ソフトウェア修正システム、ソフトウェア修正方法、及び、ソフトウェア修正プログラム
US9098292B1 (en) * 2014-04-29 2015-08-04 The Mathworks, Inc. Automatic generation of an optimized arrangement for a model and optimized code based on the model
JP2017068825A (ja) * 2015-09-29 2017-04-06 パナソニックIpマネジメント株式会社 ソフトウェア開発システムおよびプログラム

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021157073A1 (ja) * 2020-02-07 2021-08-12 三菱電機株式会社 情報処理装置、情報処理方法および情報処理プログラム
JPWO2021157073A1 (ja) * 2020-02-07 2021-08-12
JP7023439B2 (ja) 2020-02-07 2022-02-21 三菱電機株式会社 情報処理装置、情報処理方法および情報処理プログラム

Also Published As

Publication number Publication date
JP6632777B2 (ja) 2020-01-22
TW201933165A (zh) 2019-08-16
JPWO2019142469A1 (ja) 2020-01-23
WO2019142267A1 (ja) 2019-07-25

Similar Documents

Publication Publication Date Title
CA3021168C (en) Anticipatory cyber defense
US11036867B2 (en) Advanced rule analyzer to identify similarities in security rules, deduplicate rules, and generate new rules
JP2019500676A (ja) ソフトウェア開発のためのソフトウェアリスク制御方法およびシステム
CN103262088B (zh) 评估应用代码中的降级器代码的方法和装置
JP2020160611A (ja) テストシナリオ生成装置、テストシナリオ生成方法、テストシナリオ生成プログラム
US20150067834A1 (en) Building Reusable Function Summaries for Frequently Visited Methods to Optimize Data-Flow Analysis
CN112016138A (zh) 一种车联网自动化安全建模的方法、装置和电子设备
WO2019142469A1 (ja) セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム
Aidee et al. Vulnerability assessment on ethereum based smart contract applications
WO2021183382A1 (en) Graph-based method for inductive bug localization
JP7008879B2 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
US20200274901A1 (en) Security design planning support device
CN110674491B (zh) 用于安卓应用的实时取证的方法、装置和电子设备
JP6274090B2 (ja) 脅威分析装置、及び脅威分析方法
JP6608569B1 (ja) セキュリティ設計装置、セキュリティ設計方法およびセキュリティ設計プログラム
WO2020115853A1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
Wijitrisnanto et al. Efficient Machine Learning Model for Hardware Trojan Detection on Register Transfer Level
TWI715647B (zh) 用於智慧財產(ip)指紋法與ip dna分析之系統及方法
JP7292505B1 (ja) 攻撃シナリオ生成装置、攻撃シナリオ生成方法、および、攻撃シナリオ生成プログラム
JP6599053B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
WO2024048040A1 (ja) セキュリティリスクアセスメント支援方法及びセキュリティリスクアセスメント支援システム
JP6818568B2 (ja) 通信装置、通信仕様差分抽出方法及び通信仕様差分抽出プログラム
WO2021075577A1 (ja) 生成装置、プログラム、及び生成方法
WO2024069877A1 (ja) 評価装置、事業者端末、評価システム、評価方法、及び記録媒体
US20220382876A1 (en) Security vulnerability management

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2019538449

Country of ref document: JP

Kind code of ref document: A

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18901624

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18901624

Country of ref document: EP

Kind code of ref document: A1