WO2022113348A1

WO2022113348A1 - Development side security analysis support device, operation side security analysis support device, and security analysis support system

Info

Publication number: WO2022113348A1
Application number: PCT/JP2020/044522
Authority: WO
Inventors: 修治宮下; 陽一郎古賀
Original assignee: 三菱電機株式会社
Priority date: 2020-11-30
Filing date: 2020-11-30
Publication date: 2022-06-02
Also published as: JP7403686B2; JPWO2022113895A1; WO2022113895A1

Abstract

The objective of the present disclosure is to provide a development side security analysis support device capable of efficiently improving the quality of security. A development side security analysis support device according to the present disclosure is provided with: a security demand inferring unit which infers a security demand by inputting data including a feature of a development target, a required specification of the development target, and a predetermined provision to which the development target conforms, into a security demand prediction model for predicting a security demand matching the development target; a security requirement acquiring unit which, on the basis of the security demand inferred by the security demand inferring unit, acquires a security requirement corresponding to the security demand, from a first database which stores information representing a correspondence between security demands and security requirements; and a design information inferring unit which infers design information by inputting the security requirement acquired by the security requirement acquiring unit into a design information selection model for selecting design information for implementing a security function matching the development target.

Description

Development side security analysis support device, operation side security analysis support device, and security analysis support system

This disclosure relates to a development side security analysis support device, an operation side security analysis support device, and a security analysis support system that detect an attack on a target product and perform maintenance and operation.

Conventional product security analyzers use functional application model information modeled using system specification information for functional applications included in the target system, and vulnerabilities modeled using system specification information for vulnerabilities contained in case studies. We conducted a threat analysis of the target system based on the sex model information. (See, for example, Patent Document 1). In addition, other techniques related to threat analysis are also disclosed (see, for example, Non-Patent Document 1).

International Publication No. 2019/093059

In the conventional threat analysis technology, only "requirement extraction" at the conceptual design level of software is taken up for the analysis work of product security threats and vulnerabilities, and "requirement extraction" at the more specific system level is taken up. "Requirement extraction" and "function selection" of system design required separate manual work by the developer. Therefore, regarding security, the man-hours from "requirement extraction" to "function selection" have increased, and the quality is not constant and personalized depending on the skill level of the worker.

Furthermore, the "development side" and "operation side" of the product could not automate the information linkage between the two, and feedback to the "development side" about new threats found on the operation side may be delayed. .. On the other hand, the vulnerabilities known on the "development side" and their countermeasures could not be quickly and sufficiently deployed to the "operation side".

In this way, the conventional threat analysis technology could not efficiently improve the quality of security.

This disclosure is made to solve such problems, and is capable of efficiently improving the quality of security on the development side security analysis support device, the operation side security analysis support device, and the security analysis support. The purpose is to provide a system.

In order to solve the above problems, the development-side security analysis support device according to the present disclosure uses a security requirement prediction model for predicting security requirements that match the development target, the characteristics of the development target, the required specifications of the development target, and the requirements. A security requirement inference unit that infers security requirements by inputting data including predetermined rules to which the development target complies, and security requirements and security requirements based on the security requirements inferred by the security requirement inference unit. From the first database that stores the information indicating the correspondence, the security requirement acquisition unit that acquires the security requirements corresponding to the security requirements and the design information selection model for selecting the design information that realizes the security function suitable for the development target. , A design information inference unit for inputting security requirements acquired by the security requirement acquisition unit and inferring design information is provided.

According to this disclosure, it is possible to efficiently improve the quality of security.

The purposes, features, aspects, and advantages of the present disclosure will be made clearer by the following detailed description and accompanying drawings.

It is a block diagram which shows the outline of the whole structure of the development side security analysis support apparatus by Embodiment 1. FIG. It is a block diagram which shows the detail of the structure of the development side security analysis support apparatus by Embodiment 1. FIG. It is a block diagram which shows the detail of the structure of the development side security analysis support apparatus by Embodiment 1. FIG. It is a block diagram which shows the detail of the structure of the development side security analysis support apparatus by Embodiment 1. FIG. It is a figure which shows an example of the characteristic confirmation sheet of the product by Embodiment 1. FIG. It is a figure which shows an example of the characteristic confirmation sheet of the product by Embodiment 1. FIG. It is a figure which shows an example of the system feature DB by Embodiment 1. FIG. It is a figure which shows an example of the failure DB by Embodiment 1. FIG. It is a figure which shows an example of the threat DB by Embodiment 1. FIG. It is a figure which shows an example of the countermeasure DB by Embodiment 1. FIG. It is a figure which shows an example of the vulnerability information DB by Embodiment 1. FIG. It is a figure which shows an example of the operation log signature DB by Embodiment 1. FIG. It is a figure which shows an example of the project DB by Embodiment 1. FIG. It is a figure which shows an example of the specification document / design document DB by Embodiment 1. FIG. It is a figure which shows an example of the security standard DB by Embodiment 1. FIG. It is a figure which shows an example of the law / regulation DB by Embodiment 1. FIG. It is a figure for demonstrating a three-layer neural network. It is a flowchart which shows the acquisition and accumulation of the data in the learning part by Embodiment 1. FIG. It is a flowchart which shows the acquisition and accumulation of the data in the learning part by Embodiment 1. FIG. It is a flowchart which shows the generation process of the security requirement prediction model in the learning part by Embodiment 1. FIG. It is a flowchart which shows the generation process of the design information selection model in the learning part by Embodiment 1. FIG. It is a flowchart which shows the inference processing in the inference part by Embodiment 1. It is a figure which shows an example of the security requirement information sheet by Embodiment 1. FIG. It is a figure which shows an example of the security requirement information sheet by Embodiment 1. FIG. It is a figure which shows an example of the security design information sheet by Embodiment 1. FIG. It is a block diagram which shows the outline of the whole structure of the operation side security analysis support apparatus by Embodiment 2. FIG. It is a block diagram which shows the detail of the structure of the operation side security analysis support apparatus by Embodiment 2. FIG. It is a figure which shows an example of the signature update list file by Embodiment 2. FIG. It is a figure which shows an example of the operation / maintenance analysis DB by Embodiment 2. It is a flowchart which shows the generation process of the security monitoring model in the learning part by Embodiment 2. FIG. It is a flowchart which shows the inference processing in the inference part by Embodiment 2. It is a flowchart which shows the inference processing in the inference part by Embodiment 2. It is a figure which shows an example of the knowledge file obtained from the operation of the product in the market by Embodiment 2. FIG. It is a figure which shows an example of the knowledge file obtained from the operation of the product in the market by Embodiment 2. FIG.

<Embodiment 1>
<1. Configuration>
FIG. 1 is a block diagram showing a configuration of the development side security analysis support device 10 according to the first embodiment. FIGS. 2, 3 and 4 are block diagrams showing details of the configuration of the development side security analysis support device 10. 2 and 3 are connected by BL1-BL2, and FIGS. 3 and 4 are connected by BL3-BL4.

The development side security analysis support device 10 is a device that supports the analysis of the developer regarding the extraction of security requirements and the selection of security functions of the product to be developed. After the product development is completed and shipped to the market, it becomes a product (field) 90 (see FIGS. 26 and 27 described later), and the operation log monitoring knowledge is fed back from the operation side security analysis support device 50 to cooperate. , To enable faster extraction of security requirements and selection of security features in similar product development projects. The project in the present disclosure means a project for product (device) development, system development, etc. accompanied by software development and design.

The development side security analysis support device 10 includes a main storage unit 100, an auxiliary storage unit 200, an interface unit 300, and a processor 400. Further, the development side security analysis support device 10 is connected to the display device 500 and the input / output device 600. The development side security analysis support device 10 is, for example, a personal computer.

The processor 400 is connected to other hardware via a signal line. The processor 400 includes a central processing unit (CPU: Central Processing Unit), MPU (MicroProcessingUnit), DSP (DigitalSignalProcessor), GPU (GraphicsProcessingUnit), microcomputer, FPGA (FieldProgrammableGateArray), and ASIC (Application). It can be realized by Specific Integrated Circuit). The processor 400 realizes various functions by reading an OS (Operating System), an application program, and various data stored in an auxiliary storage unit 200, which will be described later, and executing arithmetic processing. The processor 400 includes a functional configuration described later. The functional configuration may be realized by firmware. The hardware that combines the processor 400, the main storage unit 100 and the auxiliary storage unit 200, which will be described later, is also referred to as a "processing circuit relay".

The main storage unit 100 is a volatile storage unit. The main storage unit 100 can be realized by a RAM (RandomAccessMemory) or the like. The main storage unit 100 temporarily stores data that is used in the development side security analysis support device 10 and is generated, input / output, or transmitted / received. Further, the main storage unit 100 includes a data collection unit 101, a multimodal feature analysis unit 102, a data primary processing integration unit 103, a security request extraction data acquisition preprocessing unit 104, and a security request prediction model generation unit 105 (first model generation). Unit), security function selection data acquisition pre-processing unit 106, design information selection model generation unit 107 (second model generation unit), product planning data acquisition unit 108, security request inference unit 109, cost / schedule adjustment unit 110, security It includes a requirement acquisition unit 111, a security function inference unit 112, a security monitoring data acquisition preprocessing unit 113, a security monitoring model generation unit 114, and a threat / countermeasure comparison cooperation update unit 115.

The data collection unit 101 has existing data of past project data, vulnerability analysis result information, specifications / design documents, legal / regulatory information, security standards, product operation logs in the past market, and incident signature information. Is collected and sent to the data lake 210.

The multimodal feature analysis unit 102 combines natural language processing and image recognition results to determine product specifications, applicable laws / regulations and standards, threats, trust boundaries, demarcation of responsibilities, costs, and periods. Organize the characteristics of failure classification, countermeasures, attackers, attack routes, failure information, operation logs, and signatures, and their relationships. Here, laws, regulations and standards are also described as "predetermined rules".

Data primary processing integration unit 103 deletes data check, cleansing, confidential information and unnecessary characters from the syntactic analysis results of natural language processing.

The security request extraction data acquisition pre-processing unit 104 inputs each of product features, requirement specifications (specifications including system configuration diagram), compliant laws and regulations, and security standards, and a security request (a security request that serves as a correct answer label for each input). Obtain and prepare teacher data showing the correspondence with threats, trust boundaries, and demarcation of responsibilities. Further, the security request extraction data acquisition preprocessing unit 104 performs preprocessing so that the prepared data can be machine-learned.

The security request prediction model generation unit 105 performs supervised learning using the teacher data preprocessed by the security request extraction data acquisition preprocessing unit 104, and predicts security requests (threats, trust boundaries, responsibility demarcation) (security). Demand prediction model) is generated.

The security function selection data acquisition pre-processing unit 106 selects security requirements (threats, trust boundaries, demarcation of responsibilities, costs, schedules) and security functions that serve as correct labels for the security requirements (fault classification, countermeasures, attackers, attacks). Acquire and prepare teacher data showing the correspondence with the route). Further, the security function selection data acquisition preprocessing unit 106 performs preprocessing so that the prepared data can be machine-learned.

The design information selection model generation unit 107 performs supervised learning using the teacher data preprocessed by the security function selection data acquisition preprocessing unit 106, and selects security functions (fault classification, countermeasures, attackers, attack routes). Generate a model to be performed (design information selection model).

The product planning data acquisition unit 108 is a feature confirmation sheet of the product to be developed entered by the developer via the input / output device 600, compliant laws / regulations and security standards, and each data of required specifications (specifications including system configuration diagram). Acquire (product planning data). An example of the feature confirmation sheet is shown in FIGS. 5 and 6. 5 and 6 are connected by BL6-BL7.

The security requirement inference unit 109 inputs each data of the feature confirmation sheet of the product to be developed, the applicable laws / regulations and standards, and the requirement specifications (specifications including the system configuration diagram), and performs multimodal inference from the supervised learning model. Perform (infer with the security requirement prediction model) and output the expected security requirements (threat, trust boundary, demarcation of responsibility) for the product to be developed.

The cost / schedule adjustment unit 110 calculates the cost and schedule from the threats, trust boundaries, and responsibility demarcations assumed from the product to be developed.

The security requirement acquisition unit 111 acquires the security requirement data of the product to be developed according to the cost and schedule, and inputs the data to the security function inference unit 112.

The security function inference unit 112 inputs the security requirements of the product to be developed according to the cost and schedule, infers with the design information selection model, and outputs the security design information (recommended proposal of the security function) corresponding to the security requirements. .. Security design information is design information that realizes security functions suitable for the product to be developed.

The security monitoring data acquisition pre-processing unit 113 preprocesses the prepared data and transmits it to the security monitoring model generation unit 114.

The security monitoring model generation unit 114 is a failure classification that serves as a correct answer label for inputting product information, failure information, and operation log (normal / abnormal) data of the operation log signature DB (Database, the same applies hereinafter), the failure DB, and the system feature DB. , Threats, signatures, countermeasures, attackers, and attack routes are generated so that a model (security monitoring model) that makes inferences from semi-supervised learning is generated.

The threat / countermeasure comparison / linkage update unit 115 of the integrated data warehouse (DH: DataWare House) 240 if there is any content leaked in the failure classification, threat, signature, countermeasure, attacker, or attack route of abnormal data. Update the information. Hereinafter, the integrated data warehouse 240 will be referred to as an integrated DH240.

The auxiliary storage unit 200 is a non-volatile storage unit. The auxiliary storage unit 200 can be realized by a ROM (ReadOnlyMemory), an HDD (HardDiskDrive), a flash memory, or the like. The auxiliary storage unit 200 stores the OS, the application program, and various data. At least a portion of the OS is loaded into the main memory 100 and executed by the processor 400.

The auxiliary storage unit 200 includes a data lake 210 in which both structured data and unstructured data collected from the data collection unit 101 are stored. Further, as shown in FIG. 3, the auxiliary storage unit 200, as an integrated DH240, is a system feature DB 241 which is a plurality of databases converted into structured data, a failure DB 242, a threat DB 243, a countermeasure DB 244, a vulnerability information DB 245, and an operation. Includes log signature DB246, project DB247, specification / design document DB248, security standard DB249, and law / regulation DB250.

Further, the auxiliary storage unit 200 stores a security requirement prediction model storage database 220 that stores a security requirement prediction model generated based on machine learning of supervised learning, and design information generated based on machine learning of supervised learning. The design information selection model storage database 230 for storing the selection model is included.

The system feature DB 241 stores the degree of influence in health, safety, and environment when a security incident occurs as a feature of the product system. The sample data of the system feature DB 241 is shown in FIG.

The failure DB 242 stores the failure occurrence status when a security incident occurs, the cause analysis, the countermeasure content, and the like. Further, the failure DB 242 is composed of information such as a failure occurrence date and time, a failure classification, a product category, a unit name, a product serial number, a failure content, a cause, and countermeasures. The sample data of the failure DB 242 is shown in FIG.

The threat DB 243 covers the types of threats assumed for the product, and stores the attacker who executes the threat and the corresponding security requirements. Further, the threat DB 243 is composed of information such as assumed threats, performers, security requirements, assumed failures, and attack routes. The sample data of the threat DB 243 is shown in FIG.

The countermeasure DB 244 stores the types of threats assumed for the product, the security requirements thereof, the corresponding countermeasure contents, and the like. The countermeasure DB 244 is composed of information such as assumed threats, security requirements, and security function candidates. Countermeasure DB 244 sample data is shown in FIG.

The vulnerability information DB 245 stores the vulnerabilities related to the software constituting the product, the CWE (Common Weakness Enumeration) classification, the corresponding signature, and the like. The vulnerability information DB 245 is composed of the title of the vulnerability, the software type, the last update date, the countermeasure, the CWE, the signature introduction status, and the corresponding signature number. FIG. 11 shows sample data of the vulnerability information DB 245.

The operation log signature DB 246 stores the operation log data when an abnormality occurs in a product that has already been shipped to the existing market, and the signature number in which the IPS (Intrusion Prevention System) function of the device on the trust boundary detects the abnormality. .. The signature is a series of bytes (byte sequence) common to abnormal operations of a specific malware sample or the like. Further, the operation log signature DB 246 is composed of information such as a log No., a product serial number, a product code, a detected signature number, and a detection date and time. FIG. 12 shows sample data of the operation log signature DB 246.

The project DB 247 stores the logs of abnormal and normal test results acquired in the system test and the equipment on the assumed trust boundary in the product development project. Further, the project DB 247 is composed of a project ID, a unit name, a product code, a software type, a product group, a test log No. (normal), a test log No. (abnormal), and information on devices on the trust boundary. The sample data of the project DB 247 is shown in FIG.

The specification / design document DB248 shows the traceability of security-related requirements, requirements, and design documents, and is composed of information on the correspondence between the requirements, requirements, and external design documents. The sample data of the specification / design document DB248 is shown in FIG.

The security standard DB 249 stores the security standard name that the product generally conforms to and the standard name that additionally conforms to each individual project. Further, the security standard DB 249 is composed of information such as a type and a standard name. The sample data of the security standard DB 249 is shown in FIG.

Laws / regulations DB250 shows what kind of security-related laws / regulations are applied to products in domestic and overseas regional divisions. Further, the law / regulation DB 250 is composed of information such as a region classification, a name of a law / regulation, and a product group. FIG. 16 shows sample data of the law / regulation DB 250.

The security request prediction model storage DB 220 stores the security request prediction model that has been learned by supervised learning generated by the security request prediction model generation unit 105.

The design information selection model storage DB 230 stores the design information selection model that has been learned by supervised learning generated by the design information selection model generation unit 107.

The display device 500 displays a character string and an image according to a user operation. The display device 500 includes a liquid crystal display, an organic EL (Electro Luminescence) display, and the like. The display device 500 may be integrally configured with the development side security analysis support device 10.

The input / output device 600 is composed of a keyboard, a mouse, a numeric keypad, and the like. The user operates the development side security analysis support device 10 via the input / output device 600. Further, the input / output device 600 may include a touch panel that is integrally arranged with the display device 500 and can accept a user's touch operation. The input / output device 600 may be integrally configured with the development side security analysis support device 10.

The interface unit 300 transmits and receives various data to and from the operation side security analysis support device 50. The interface unit 300 includes a receiver and a transmitter (not shown). The receiver receives various data from the operation side security analysis support device 50. The transmitter transmits various data from the processor 400 to the operation side security analysis support device 50. The interface unit 300 can be realized by a communication chip, a NIC (Network Interface Card), or the like.

As shown in FIGS. 2 to 4, the development side security analysis support device 10 includes a learning unit centered on a security request prediction model generation unit 105 and a design information selection model generation unit 107, a security request inference unit 109, and a security function inference. It is roughly divided into an inference unit centered on the unit 112.

The learning unit and the inference unit are used to learn the security requirements of the target product and the output of the security request function selection. For example, they are connected to the target product via a network and are separate from the target product. It may be a device. Further, the learning unit and the inference unit may be built in the target product. Further, the learning unit and the inference unit may exist on the cloud server.

As the learning algorithm used by the security requirement prediction model generation unit 105 and the design information selection model generation unit 107, a known algorithm for supervised learning can be used. In the following, a case where a neural network is applied will be described as an example.

The security requirement prediction model generation unit 105 and the design information selection model generation unit 107 perform learning to output by so-called supervised learning according to, for example, a neural network model. Here, supervised learning refers to a method of learning a feature in those learning data by giving a set of input and result (label) data to the learning unit, and inferring the result from the input.

A neural network is composed of an input layer consisting of a plurality of neurons, an intermediate layer (hidden layer) consisting of a plurality of neurons, and an output layer consisting of a plurality of neurons. The intermediate layer may be one layer or two or more layers.

For example, in the case of a three-layer neural network as shown in FIG. 17, when a plurality of inputs are input to the input layer (X1-X3), the value is multiplied by the weight W1 (w11-w16) to form an intermediate layer (w11-w16). It is input to Y1-Y2), and the result is further multiplied by the weight W2 (w21-w26) and output from the output layer (Z1-Z3). This output result depends on the values of the weights W1 and W2.

In this disclosure, learning is performed in the following two neural network models. The first neural network is the input input data (product features, requirement specifications (specifications including system configuration diagram), compliant laws / regulations and security standards) acquired by the security requirement extraction data acquisition preprocessing unit 104. , The output is learned by so-called supervised learning according to the learning data created based on the combination of the corresponding correct inputs (security requirements (threat, trust boundary, demarcation of responsibility)).

In addition, the second neural network is the input (security requirements (security requirements (threat, trust boundary, demarcation of responsibility, cost, schedule)) acquired by the security function selection data acquisition preprocessing unit 106, and the corresponding input that is the correct answer. The output is learned by so-called supervised learning according to the learning data created based on the combination of (selection of security functions (fault classification, countermeasures, attackers, attack routes)).

That is, the neural network learns by inputting input data as an input to the input layer and adjusting the weights W1 and W2 so that the result output from the output layer approaches the input data (correct answer).

The security requirement prediction model generation unit 105 and the design information selection model generation unit 107 generate and output a trained model (security requirement prediction model, design information selection model) by executing the above learning.

<2. Operation>
Next, the operations of the learning unit and the inference unit of the development side security analysis support device 10 configured as described above will be described with reference to FIGS. 18 to 22.

<2-1. Learning phase ＞
<2-1-1. Data acquisition step>
18 and 19 are flowcharts regarding data acquisition and storage in the learning unit. Hereinafter, the operation of the learning unit will be described according to the flowcharts shown in FIGS. 18 and 19.

In step S101, the data collection unit 101 has existing data such as past project data 601, vulnerability analysis result information 602, specification / design document 603, legal / regulatory information 604, security standard 605, and products in the past market. The operation log and incident signature information 606 of the above are collected and transmitted to the data lake 210.

In step S102, the data lake 210 accumulates the data transmitted from the data collecting unit 101. In step S103, the data lake 210 determines whether the accumulated data is structured data. If it is not structured data, step S104 determines whether the data has regularity. If there is no regularity, in step S105, it is determined whether or not the data is text data.

In the case of text data, in step S106, the syntax analysis of natural language processing is performed, and the required specifications of the product plan are extracted from the result. If it is not text data, that is, if it is image data or the like, in step S107, the system configuration diagram and the image recognition process for the system configuration diagram are performed, and the system configuration and the trust boundary are identified from the result.

In step S108, the multimodal feature analysis unit 102 receives the processing results of steps S106 and S107, multiplies the natural language processing and the image recognition result, and the product specifications according to the system configuration and the applicable laws and regulations. And organize the characteristics and relationships of standards, threats, trust boundaries, demarcation of responsibilities, costs, duration, failure classification, countermeasures, attackers, attack routes, failure information, operation information, and signatures.

In step S109, the data primary processing integration unit 103 is unified to the JSON format. In step S110, the data primary processing integration unit 103 deletes data checking, cleansing, confidential information, and unnecessary characters from the parsing result of natural language processing.

In step S111, the data primary processing integration unit 103 converts all the data into the CSV format. In step S112, the integrated DH240 has a system feature DB 241, a failure DB 242, a threat DB 243, a countermeasure DB 244, a vulnerability information DB 245, an operation log signature DB 246, a project DB 247, a specification / design document DB 248, a security standard DB 249, and a law / regulation DB 250. Store data in.

<2-1-2. Security requirement prediction model generation step>
FIG. 20 is a flowchart relating to the learning process of the security requirement prediction model in the learning unit. Hereinafter, the operation of the learning unit will be described according to the flowchart shown in FIG.

In step S201, the security requirement extraction data acquisition preprocessing unit 104 inputs the product features, requirement specifications, applicable laws / regulations and security standards, and the security requirements (threats, trust boundaries, responsibilities) that serve as correct labels for the inputs. The teacher data showing the correspondence with the boundary) is acquired, and preparations are made for preprocessing of machine learning.

In step S202, the security request extraction data acquisition preprocessing unit 104 preprocesses the prepared data so that it can be machine-learned. In step S203, the security requirement prediction model generation unit 105 performs supervised learning using the preprocessed teacher data, and generates a model for predicting security requirements (threat, trust boundary, responsibility demarcation). In step S204, the security request prediction model storage DB 220 stores the generated prediction model in its own DB.

<2-1-3. Design information selection model generation step>
FIG. 21 is a flowchart relating to the learning process of the design information selection model in the learning unit. Hereinafter, the operation of the learning unit will be described according to the flowchart shown in FIG.

In step S301, the security function selection data acquisition preprocessing unit 106 selects security requirements (threats, trust boundaries, demarcation of responsibilities, costs, schedules) and security functions that serve as correct labels for the security requirements (fault classification, countermeasures, Acquire teacher data showing the correspondence with the attacker and attack route), and prepare to perform preprocessing for machine learning.

In step S302, the security function selection data acquisition preprocessing unit 106 preprocesses the prepared data so that it can be machine-learned.

In step S303, the design information selection model generation unit 107 performs supervised learning using preprocessed teacher data, and generates a model that predicts the selection of security functions (fault classification, countermeasures, attackers, attack routes). .. In step S304, the design information selection model storage DB 230 stores the generated prediction model in its own DB.

<2-2. Inference phase>
FIG. 22 is a flowchart relating to the inference processing of the inference unit. Hereinafter, the operation of the inference unit will be described according to the flowchart shown in FIG.

In step S401, the product planning data acquisition unit 108 includes laws, regulations, standards 651, and required specifications (including a system configuration diagram) that comply with the feature confirmation sheet 653 of the product to be developed entered by the developer via the input / output device 600. Specifications) 652 is acquired.

In step S402, the product planning data acquisition unit 108 collects the feature amount of the data in the laws / regulations and standards 651 and the required specifications 652 that comply with the feature confirmation sheet 653 of the product to be developed of the acquired product, and secures the security. Input to the request inference unit 109.

In step S403, the security requirement inference unit 109 inputs the features of the product to be developed, the requirement specifications (specifications including the system configuration diagram), the compliant laws and regulations, and the security standard, and performs multimodal inference from the supervised learning model. Perform (infer inference with security requirement prediction model) and output security requirements (threat, trust boundary, demarcation of responsibility) to be developed. In the inference in the security requirement prediction model, system feature DB241, failure DB242, threat DB243, project DB247, specifications / design document DB248, security standard DB249, laws / regulations / regulations are used to classify security requirements for assumed threats. See DB 250.

In step S404, the cost / schedule adjustment unit 110 calculates the cost and schedule from the threats, trust boundaries, and responsibility demarcation points assumed from the development target product, and outputs the security requirement information sheet 654 of the development target product. An example of the security requirement information sheet 654 is shown in FIGS. 23 and 24.

In step S405, the security requirement acquisition unit 111 acquires the data of the security requirement information sheet 654 of the development target product, which is the security requirement of the development target product according to the cost and schedule, and inputs the data to the security function inference unit 112. ..

In step S406, the security function inference unit 112 infers with the design information selection model by inputting the security requirements of the product to be developed according to the cost and schedule, and is a development target that is a recommended proposal of the security function corresponding to the security requirements. Output the product security design information sheet 655. In the inference in the design information selection model, the countermeasure DB 244 is referred to in order to classify the correspondence of the function candidates corresponding to the security requirements for the assumed threat. FIG. 25 shows an example of the security design information sheet 655.

<3. Effect>
According to the first embodiment, the development side security analysis support device 10 automatically performs "function selection" in addition to "requirement extraction" related to security analysis at the system level. Therefore, there is an effect of shortening the time of security analysis for known threats before product shipment, and it is possible to achieve efficient security quality improvement that is not personal. That is, it is possible to efficiently improve the quality of security.

<Embodiment 2>
The development-side security analysis support device 10 described in the first embodiment generates a security design information sheet 655 or the like of the product to be developed and ends the operation. The operation-side security analysis support device 50 described in the second embodiment learns a security monitoring model based on the vulnerability information and the operation log data information stored in the vulnerability information DB 245 and the operation log signature DB 246. .. Then, the abnormality is detected from the operation log of the product (product to be operated) in the actual market, the IPS signature of the product on the operation side is updated, and the threats on the development side and the contents of countermeasures are also updated.

<1. Configuration>
FIG. 26 is a block diagram showing a configuration of the operation side security analysis support device 50 according to the second embodiment. FIG. 27 is a block diagram showing details of the configuration of the operation side security analysis support device 50.

The operation side security analysis support device 50 analyzes the operation log after the product development is completed and shipped to the market, determines an abnormality, updates the signature, and performs security analysis on the product to be developed on the development side. Give feedback to the support device.

The operation side security analysis support device 50 includes a main storage unit 900, an auxiliary storage unit 1000, a communication unit 700 that communicates with the development side security analysis support device, and a communication unit 1100 that communicates with the product 90 (field). It is equipped with a processor 800. Further, the operation side security analysis support device 50 is connected to the display device 1200 and the input / output device 1300. The operation side security analysis support device 50 is, for example, a personal computer.

The processor 800 is connected to other hardware via a signal line. The processor 800 can be realized by a central processing unit (CPU), an MPU, a DSP, a GPU, a microcomputer, an FPGA, an ASIC, or the like. The processor 800 realizes various functions by reading the OS, the application program, and various data stored in the auxiliary storage unit 1000, which will be described later, and executing arithmetic processing. The processor 800 includes a functional configuration described later. The functional configuration may be realized by firmware. The hardware that combines the processor 800, the main storage unit 900 and the auxiliary storage unit 1000, which will be described later, is also referred to as a "processing circuit".

The main storage unit 900 is a volatile storage unit. The main storage unit 900 can be realized by RAM or the like. The main storage unit 900 is used in the operation side security analysis support device 50, and temporarily stores data generated, input / output, or transmitted / received. Further, the main storage unit 900 includes an operation log data acquisition unit 901, an operation log data preprocessing unit 902, a security monitoring model inference unit 903, a signature data comparison unit 904, and a signature information update unit 905.

The operation log data acquisition unit 901 acquires the operation / maintenance analysis log data stored in the operation / maintenance analysis DB 1002.

The operation log data pre-processing unit 902 performs data conversion pre-processing so that the operation log data can be machine-learned.

The security monitoring model inference unit 903 infers from the semi-supervised learning model by inputting product information, failure information, and operation information (normal, abnormal), and fails classification, threats, signatures, countermeasures, and attackers of the failure abnormality data. , Output the attack route.

The signature data comparison unit 904 transmits information on the fault classification, threat, signature, countermeasure, attacker, and attack route of abnormal data to the interface unit 300 of the development side security analysis support device 10. Further, when there is an abnormality in the log data, the signature data comparison unit 904 creates a signature update list file after comparing it with the currently registered signature data and transmits it to the signature information update unit 905. FIG. 28 shows an example of the signature update list file.

The signature information update unit 905 issues the signature update data and the update command, and distributes the signature data to the centralized controller 2004.

The auxiliary storage unit 1000 is a non-volatile storage unit. The auxiliary storage unit 1000 can be realized by a ROM, an HDD, a flash memory, or the like. The auxiliary storage unit 1000 stores the OS, the application program, and various data. At least a portion of the OS is loaded into main memory 900 and executed by processor 800.

The auxiliary storage unit 1000 includes a security monitoring model storage DB 1001 that stores a security monitoring model generated based on machine learning of semi-supervised learning, and an operation / maintenance analysis DB 1002 that stores operation log data of products in the market. ..

The security monitoring model storage DB 1001 stores the security monitoring model that has been learned by semi-supervised learning generated by the security monitoring model generation unit 114.

The operation / maintenance analysis DB 1002 is composed of information such as log No., product serial number, product code, supported signature number, log acquisition date / time, failure information, and operation information. FIG. 29 shows sample data of the operation / maintenance analysis DB 1002.

The display device 1200 displays a character string and an image according to the operation of the operation / maintenance person. The display device 1200 is composed of a liquid crystal display, an organic EL display, and the like. The display device 1200 may be integrally configured with the operation side security analysis support device 50.

The input / output device 1300 is composed of a keyboard, a mouse, a numeric keypad, and the like. The operation / maintenance person operates the operation side security analysis support device 50 via the input / output device 1300. Further, the input / output device 1300 may include a touch panel that is integrally configured with the display device 1200 and can accept touch operations of maintenance / operation personnel.

The communication unit 700 sends and receives various data between the operation side security analysis support device 50 and the development side security analysis support device 10. The communication unit 700 and the communication unit 1100 include a receiver and a transmitter (not shown). The receiver receives various data from the development side security analysis support device 10 and the remote monitoring device 2001. The transmitter transmits various data from the processor 800 to the development side security analysis support device 10 and the remote monitoring device 2001. The communication unit 700 and the communication unit 1100 can be realized by a communication chip, a NIC, or the like.

The operation side security analysis support device 50 is roughly divided into a learning unit centered on the security monitoring model generation unit 114 and an inference unit centered on the security monitoring model inference unit 903.

As the learning algorithm used by the security monitoring model generation unit 114, a known algorithm for semi-supervised learning can be used. As an example, a case where a neural network is applied will be described.

The security monitoring model generation unit 114 learns to output by so-called semi-supervised learning according to, for example, a neural network model. Here, semi-supervised learning refers to a method of learning a feature in the learning data by giving a set of input and result (label) data to the learning device, and inferring the result from the input.

In this disclosure, learning is performed in the following neural network model. In the neural network, the input input data (product information, failure information, operation information (normal, abnormal)) acquired by the security monitoring data acquisition preprocessing unit 113 and the corresponding input (fault classification, threat, signature) are correct. , Countermeasures, attackers, attack routes), and the output is learned by so-called semi-supervised learning according to the learning data created based on the combination.

The security monitoring model generation unit 114 generates and outputs a trained model (security monitoring model) by executing the above learning.

<2. Operation>
Next, the operations of the learning unit and the inference unit of the operation-side security analysis support device 50 configured as described above will be described with reference to FIGS. 30 to 32.

<2-1. Learning phase ＞
FIG. 30 is a flowchart regarding the learning process of the security monitoring model in the learning unit. Hereinafter, the operation of the learning unit will be described according to the flowchart shown in FIG.

In step S501, the security monitoring data acquisition preprocessing unit 113 inputs product information, failure information, and operation information (normal, abnormal), and fails classification, threat, signature, countermeasure, attacker, which is a correct label for the input. Acquire teacher data showing the correspondence with the attack route.

In step S502, the security monitoring data acquisition preprocessing unit 113 performs machine learning preprocessing and transmits it to the security monitoring model generation unit 114.

In step S503, the security monitoring model generation unit 114 performs supervised learning using preprocessed teacher data, and creates a model (security monitoring model) that predicts failure classification, threats, signatures, countermeasures, attackers, and attack routes. Generate.

In step S504, the interface unit 300 of the development side security analysis support device 10 transmits data to the communication unit 700 of the operation side security analysis support device 50.

In step S505, the security monitoring model storage DB 1001 stores the generated prediction model (security monitoring model) in its own DB.

<2-2. Inference phase>
31 and 32 are flowcharts related to the inference process of the inference unit. Hereinafter, the operation of the inference unit will be described according to the flowcharts shown in FIGS. 31 and 32.

In step S601, the remote monitoring device 2001 transmits a log of operation data to the communication unit 1100 via the communication line for maintenance. In step S602, the communication unit 1100 stores and stores the log data of the received operation data in the operation / maintenance analysis DB 1002.

In step S603, the operation log data acquisition unit 901 acquires the operation log from the operation / maintenance analysis DB 1002 and transmits it to the operation log data preprocessing unit 902. In step S604, the operation log data preprocessing unit 902 extracts product information, failure information, and operation information (normal / abnormal) from the operation log and inputs them to the security monitoring model inference unit 903.

In step S605, the security monitoring model inference unit 903 infers from the semi-supervised learning model by inputting product information, failure information, and operation information (normal, abnormal), and performs failure classification, threat, signature, and countermeasure of abnormal data. , Attacker, attack route is output and transmitted to the signature data comparison unit 904. The data output at this time corresponds to the knowledge file 1301 (knowledge information) obtained from the operation of the product in the market shown in FIG. 27, and an example of the knowledge file is shown in FIGS. 33 and 34. 33 and 34 are connected by BL10-BL11.

In step S606, the signature data comparison unit 904 transmits the failure classification, threat, signature, countermeasure, attacker, and attack route of abnormal data to the interface unit 300 of the development side security analysis support device 10.

In step S607, the interface unit 300 of the development side security analysis support device receives the failure classification, threat, signature, countermeasure, attacker, and attack route of abnormal data, and transfers the data to the threat / countermeasure comparison cooperation update unit 115. ..

In step S608, the threat / countermeasure comparison cooperation update unit 115 compares the contents of the fault classification, threat, signature, countermeasure, attacker, and attack route of abnormal data with the values of the existing DB, and if there is any missing content. Updates the information in the integrated DH240.

If there is an abnormality in the log data after the processing of step S605, in step S609, the signature data comparison unit 904 compares the data with the currently registered signature data, creates a signature update list file 1302, and updates the signature information. It is transmitted to the unit 905. If the signature has not been registered, registration is requested from the IDS (Intrusion Detection System) on the product side.

In step S610, the signature information update unit 905 issues signature update data and an update command thereof. In step S611, the issued signature update command and its data are transmitted to the centralized controller 2004 of the product which is a security trust boundary, and the latest signature is applied to the IPS of the centralized controller 2004.

<3. Effect>
According to the second embodiment, in the operation after the product is shipped, the operation side security analysis support device 50 includes a security monitoring mechanism on the cloud and can cooperate with the development side security analysis support device 10. Therefore, by grasping the signs of attacks against unknown threats and vulnerabilities after product shipment, it is possible to promptly detect unauthorized access and provide quick feedback to the development side security analysis support device 10. The effect of mutual cooperation between the security analysis support device 10 and the operation side security analysis support device 50 can be achieved. That is, it is possible to efficiently improve the quality of security.

Within the scope of the present disclosure, each embodiment can be freely combined, and each embodiment can be appropriately modified or omitted.

Although the present disclosure has been described in detail, the above description is exemplary in all embodiments and is not limiting. It is understood that innumerable variations not illustrated can be assumed.

10 Development side security analysis support device, 50 Operation side security analysis support device, 90 products, 100 Main storage unit, 101 Data collection unit, 102 Multimodal feature analysis unit, 103 Data primary processing integration unit, 104 Before acquisition of security request extraction data Processing unit, 105 security request prediction model generation unit, 106 security function selection data acquisition pre-processing unit, 107 design information selection model generation unit, 108 product planning data acquisition unit, 109 security request inference unit, 110 cost / schedule adjustment unit, 111 Security requirement acquisition unit, 112 security function inference unit, 113 security monitoring data acquisition pre-processing unit, 114 security monitoring model generation unit, 115 threat / countermeasure comparison cooperation update unit, 200 auxiliary storage unit, 210 data lake, 220 security request prediction model Storage DB, 230 Design information selection model Storage DB, 240 Integrated DH, 241 System feature DB, 242 Failure DB, 243 Threat DB, 244 Countermeasure DB, 245 Vulnerability information DB, 246 Operation log signature DB, 247 Project DB, 248 Specification / design document DB, 249 security standard DB, 250 law / regulation DB, 300 interface part, 400 processor, 500 display device, 600 input / output device, 601 past project data, 602 vulnerability analysis result, 603 specification / Design document, 604 law / regulation information, 605 security standard, 606 product operation log and incident signature information in the past market, 651 compliant law / regulation and security standard, 652 required specifications of development target product, 653 development target product Feature confirmation sheet, 654 security requirement information sheet for the product to be developed, 655 security design information sheet for the product to be developed, 700 communication unit, 800 processor, 900 main storage unit, 901 operation log data acquisition unit, 902 operation log data preprocessing Department, 903 Security monitoring model inference unit, 904 Signature data comparison unit, 905 Signature information update unit, 1000 Auxiliary storage unit, 1001 Security monitoring model storage DB, 1002 Operation / maintenance analysis DB, 1100 Communication unit, 1301 Product operation in the market Findings file obtained from 1302 Signature update list file, 2001 Remote monitoring device, 2002 Indoor unit, 2003 outdoor unit, 2004 centralized controller, 2005 wireless LAN, 2006 smartphone, 2007 personal computer, 2008 remote control.

Claims

Enter data including the characteristics of the development target, the required specifications of the development target, and the predetermined rules to which the development target complies in the security requirement prediction model for predicting the security requirements that match the development target. The security requirement inference unit that infers the security requirement,
A security requirement acquisition unit that acquires security requirements corresponding to the security requirements from a first database that stores information indicating the correspondence between the security requirements and the security requirements based on the security requirements inferred by the security requirement inference unit. When,
With the security function inference unit that infers the design information by inputting the security requirements acquired by the security requirement acquisition unit into the design information selection model for selecting the design information that realizes the security function suitable for the development target. ,
Development side security analysis support device equipped with.
It consists of the threat to the development target stored in the data warehouse, the characteristics of the development target contained in the information on countermeasures against the threat, the required specifications of the development target, and the predetermined provisions to which the development target complies. By learning the first input and the security requirement that is the correct answer label for the first input as teacher data, the first security requirement prediction model that predicts the security requirement that matches the development target is generated. Model generator and
The development target is obtained by learning as teacher data a second input consisting of the security requirements included in the information stored in the data warehouse and selection of a security function that serves as a correct label for the second input. A second model generation unit that generates the design information selection model for selecting the design information for
The development side security analysis support device according to claim 1.
The development-side security analysis support device according to claim 1 or 2, wherein the required specifications include a system configuration diagram.
The development-side security analysis support device according to any one of claims 1 to 3, wherein the security requirement includes a threat, a trust boundary, and a demarcation of responsibility.
The development side security analysis support device according to any one of claims 1 to 4, wherein the design information includes failure classification, countermeasures, attackers, and attack routes.
A signature information updater that acquires a signature and issues a command to update the signature,
A communication unit that receives operation log information including operation information, product information, and failure information of the operation target to which the signature is applied and stores it in the operation maintenance analysis database, which is updated by the signature information update unit.
The operation log data acquisition unit that acquires the operation log information from the operation maintenance analysis database,
The operation log information acquired by the operation log data acquisition unit is input to the learned security monitoring model in which machine learning is performed to predict the knowledge information obtained from the operation of the operation target product in the market, and the security monitoring is performed. A security monitoring model inference unit that predicts the knowledge information by executing arithmetic processing using the model, and
Operation side security analysis support device equipped with.
If the operation log information is determined to be abnormal as a result of prediction by the security monitoring model inference unit, if the signature is registered, it is compared with the registered signature, and if the signature is not registered. Is the operation side security analysis support device according to claim 6, which requests registration from the operation target side IDS (Intrusion Detection System).
The development-side security analysis support device according to any one of claims 1 to 5.
The operation-side security analysis support device according to claim 6 or 7.
Equipped with
A security analysis support system in which the development side security analysis support device and the operation side security analysis support device mutually complementarily cooperate with each other in information related to security.