JP7403686B2 - Development side security analysis support device and security analysis support system - Google Patents

Description

The present disclosure relates to a developer-side security analysis support device and a security analysis support system that detect attacks on target products and perform maintenance and operation.

Conventional product security analysis devices use functional application model information that models the functional applications included in the target system using system specification information, and vulnerabilities that model the vulnerabilities included in the example system using system specification information. Threat analysis of the target system was performed based on the gender model information (for example, see Patent Document 1). Other techniques related to threat analysis have also been disclosed (for example, see Non-Patent Document 1).

International Publication No. 2019/093059

“Microsoft Threat Modeling Tool 2018 First Step Guide”, [online], Microsoft, [searched on July 1, 2020], Internet <URL: https://docs.microsoft.com/ja-jp/azure/ security/develop/threat-modeling-tool>

Conventional threat analysis techniques only deal with "requirements extraction" at the software conceptual design level when it comes to analyzing product security threats and vulnerabilities; ``Requirements extraction'' and ``function selection'' in system design required separate manual work by developers. As a result, the number of man-hours required for security from ``requirement extraction'' to ``function selection'' increases, and the quality is not constant and depends on the skill level of the worker.

Furthermore, the ``development side'' and ``operation side'' of the product were not able to automate the coordination of information between them, and there were times when there was a delay in feedback to the ``development side'' regarding new threats discovered on the operation side. . On the other hand, vulnerabilities that became known on the ``development side'' and their countermeasures were not quickly and sufficiently distributed to the ``operation side.''

As described above, conventional threat analysis techniques have not been able to efficiently improve the quality of security.

The present disclosure has been made to solve such problems, and aims to provide a security analysis support device and a security analysis support system for developers that can efficiently improve the quality of security. purpose.

In order to solve the above problems, the development side security analysis support device according to the present disclosure includes a security requirement prediction model for predicting security requirements that match the development target, the characteristics of the development target, the requirement specifications of the development target, A security requirements inference unit infers security requirements by inputting data including predetermined regulations that the development target complies with; A security requirements acquisition unit that acquires security requirements corresponding to security requests from a first database that stores information indicating correspondence, and a design information selection model that selects design information that realizes security functions that match the development target. and a security function inference unit that inputs the security requirements acquired by the security requirement acquisition unit and infers design information.

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

Objects, features, aspects, and advantages of the present disclosure will become more apparent from the following detailed description and accompanying drawings.

1 is a block diagram showing an overview of the overall configuration of a development side security analysis support device according to Embodiment 1. FIG. FIG. 2 is a block diagram showing details of the configuration of the development side security analysis support device according to the first embodiment. FIG. 2 is a block diagram showing details of the configuration of the development side security analysis support device according to the first embodiment. FIG. 2 is a block diagram showing details of the configuration of the development side security analysis support device according to the first embodiment. FIG. 3 is a diagram showing an example of a product feature confirmation sheet according to the first embodiment. FIG. 3 is a diagram showing an example of a product feature confirmation sheet according to the first embodiment. FIG. 3 is a diagram showing an example of a system feature DB according to the first embodiment. FIG. 3 is a diagram illustrating an example of a failure DB according to the first embodiment. FIG. 3 is a diagram showing an example of a threat DB according to the first embodiment. FIG. 3 is a diagram showing an example of a countermeasure DB according to the first embodiment. FIG. 3 is a diagram showing an example of a vulnerability information DB according to the first embodiment. FIG. 3 is a diagram illustrating an example of an operation log/signature DB according to the first embodiment. FIG. 3 is a diagram showing an example of a project DB according to the first embodiment. FIG. 3 is a diagram showing an example of a specification/design document DB according to the first embodiment. FIG. 3 is a diagram showing an example of a security standard DB according to the first embodiment. FIG. 3 is a diagram showing an example of a laws and regulations DB according to the first embodiment. FIG. 2 is a diagram for explaining a three-layer neural network. 5 is a flowchart showing acquisition and accumulation of data in the learning section according to the first embodiment. 5 is a flowchart showing acquisition and accumulation of data in the learning section according to the first embodiment. 7 is a flowchart illustrating a security requirement prediction model generation process in the learning unit according to the first embodiment. 7 is a flowchart showing design information selection model generation processing in the learning unit according to the first embodiment. 7 is a flowchart showing inference processing in the inference unit according to the first embodiment. FIG. 3 is a diagram showing an example of a security requirement information sheet according to the first embodiment. FIG. 3 is a diagram showing an example of a security requirement information sheet according to the first embodiment. FIG. 3 is a diagram showing an example of a security design information sheet according to the first embodiment. FIG. 2 is a block diagram showing an overview of the overall configuration of an operation-side security analysis support device according to a second embodiment. FIG. 3 is a block diagram showing details of the configuration of an operation-side security analysis support device according to a second embodiment. 7 is a diagram illustrating an example of a signature update list file according to Embodiment 2. FIG. FIG. 7 is a diagram showing an example of an operation/maintenance analysis DB according to the second embodiment. 7 is a flowchart illustrating a security monitoring model generation process in a learning unit according to Embodiment 2. FIG. 7 is a flowchart showing inference processing in an inference unit according to Embodiment 2. FIG. 7 is a flowchart showing inference processing in an inference unit according to Embodiment 2. FIG. FIG. 7 is a diagram illustrating an example of a knowledge file obtained from the operation of a product in the market according to the second embodiment. FIG. 7 is a diagram illustrating an example of a knowledge file obtained from the operation of a product in the market according to the second embodiment. FIG. 7 is a block diagram showing details of the configuration of an operation-side security analysis support device according to Embodiment 3; 12 is a flowchart showing inference processing in an inference unit according to Embodiment 3. 12 is a block diagram showing an overview of the overall configuration of a development side security analysis support device according to a fourth embodiment. FIG. FIG. 7 is a block diagram showing details of the configuration of a development side security analysis support device according to a fourth embodiment. FIG. 7 is a block diagram showing the configuration of an integrated DH according to a fourth embodiment. FIG. 7 is a diagram showing an example of a security test/alert rule DB according to a fourth embodiment. FIG. 7 is a diagram showing an example of a security test determination result according to the fourth embodiment. 12 is a flowchart showing data acquisition, security test model generation, and inference processing in a test section according to Embodiment 4. 12 is a flowchart showing data acquisition, security test model generation, and inference processing in a test section according to Embodiment 4.

<Embodiment 1>
<1. Configuration>
FIG. 1 is a block diagram showing the configuration of a development side security analysis support device 10 according to the first embodiment. 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 FIG. 3 and FIG. 4 are connected by BL3-BL4.

The development-side security analysis support device 10 is a device that provides analytical support to developers regarding the extraction of security requirements and security function selection for products to be developed. After the product development is completed and shipped to the market, it becomes a product (field) 90 (see Figures 26 and 27 described below), and the operation side security analysis support device 50 feeds back the knowledge of operation log monitoring and cooperates. , to enable faster extraction of security requirements and selection of security functions in similar product development projects. Note that a project in this disclosure refers to a project that involves product (device) development, system development, etc. that involves software development and design.

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

Processor 400 is connected to other hardware via signal lines. The processor 400 includes a central processing unit (CPU), a micro processing unit (MPU), a digital signal processor (DSP), a graphics processing unit (GPU), a microcomputer, a field programmable gate array (FPGA), and an application chip (ASIC). Specific Integrated Circuit) etc. The processor 400 implements various functions by reading an OS (Operating System), application programs, and various data stored in the auxiliary storage unit 200, which will be described later, and executing arithmetic processing. Processor 400 includes a functional configuration described below. The functional configuration may be realized by firmware. The hardware that includes the processor 400, the main memory section 100, and the auxiliary memory section 200, which will be described later, is also referred to as "processing circuitry."

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

The data collection unit 101 collects existing data such as past project data, vulnerability analysis result information, specifications/design documents, legal/regulatory information, security standards, past product operation logs in the 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 according to the system configuration, applicable laws, regulations, and standards, threats, trust boundaries, demarcation of responsibility, cost, period, Organize the characteristics of failure classification, countermeasures, attackers, attack routes, failure information, operation logs, signatures, and their relationships. Here, laws, regulations, and standards are also referred to as "predetermined regulations."

The data primary processing and integration unit 103 checks and cleanses the data from the syntax analysis result of natural language processing, and deletes confidential information and unnecessary characters.

The security requirement extraction data acquisition pre-processing unit 104 inputs product features, required specifications (specifications including system configuration diagrams), applicable laws and regulations, and security standards, as well as security requirements (which serve as correct labels for each input). Obtain and prepare training data that shows the correspondence between threats, trust boundaries, and responsibility boundaries). Further, the security request extraction data acquisition preprocessing unit 104 performs preprocessing on the prepared data so that machine learning can be performed.

The security requirement prediction model generation unit 105 performs supervised learning using the teacher data preprocessed by the security requirement extraction data acquisition preprocessing unit 104, and creates a model (security demand prediction model).

The security function selection data acquisition preprocessing unit 106 selects security requirements (threat, trust boundary, demarcation of responsibility, cost, schedule) and the security function that is the correct label for the security requirement (fault classification, countermeasure, attacker, attack). Obtain and prepare training data that shows the correspondence relationship with (root). Further, the security function selection data acquisition preprocessing unit 106 performs preprocessing on the prepared data so that machine learning can be performed.

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 to select security functions (fault classification, countermeasures, attackers, and attack routes). Generate a model to perform (design information selection model).

The product planning data acquisition unit 108 collects data such as a feature confirmation sheet of the product to be developed, compliant laws/regulations and security standards, and required specifications (specifications including system configuration diagrams) inputted by the developer via the input/output device 600. (product planning data). Examples of feature confirmation sheets are shown in Figures 5 and 6. 5 and 6 are connected by BL6-BL7.

The security requirements inference unit 109 inputs each data of the characteristic 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 using a supervised learning model. (performs inference using a security requirements prediction model) and outputs the assumed security requirements (threats, trust boundaries, demarcation of responsibility) for the product being developed.

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

The security requirements acquisition unit 111 acquires data on the security requirements 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, performs inference using the design information selection model, and outputs security design information (recommended security function) corresponding to the security requirements. . The security design information is design information that realizes security functions suitable for the product to be developed.

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

The security monitoring model generation unit 114 generates a fault classification that serves as a correct label for the input of product information, fault information, and operation log (normal, abnormal) data in the operation log signature DB (Database, hereinafter the same), fault DB, and system feature DB. , generate a model (security monitoring model) that performs inference through semi-supervised learning so that it can output threats, signatures, countermeasures, attackers, and attack routes.

The threat/countermeasure comparison/coordination update unit 115 updates the integrated data warehouse (DH: Data Ware House) 240 if there is any content that has been omitted in the failure classification, threat, signature, countermeasure, attacker, or attack route of the abnormal data. Update information. Hereinafter, the integrated data warehouse 240 will be referred to as an integrated DH 240.

Auxiliary storage unit 200 is a nonvolatile storage unit. The auxiliary storage unit 200 can be implemented using a ROM (Read Only Memory), an HDD (Hard Disk Drive), a flash memory, or the like. The auxiliary storage unit 200 stores an OS, application programs, and various data. At least a portion of the OS is loaded into the main storage unit 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. In addition, as shown in FIG. 3, the auxiliary storage unit 200 includes, as an integrated DH 240, a system characteristics DB 241, a failure DB 242, a threat DB 243, a countermeasure DB 244, a vulnerability information DB 245, and an operation database, which are multiple databases converted into structured data. It includes a log/signature DB 246, a project DB 247, a specification/design DB 248, a security standards DB 249, and a laws/regulations DB 250.

Further, the auxiliary storage unit 200 includes a security requirement prediction model storage database 220 that stores security requirement prediction models generated based on supervised machine learning, and design information generated based on supervised machine learning. It includes a design information selection model storage database 230 that stores selection models.

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

The failure DB 242 stores the failure occurrence status, cause analysis, countermeasure details, etc. when a security incident occurs. Further, the fault DB 242 includes information such as the date and time of fault occurrence, fault classification, product category, unit name, product serial number, fault details, causes, and countermeasures. 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, the corresponding security requirements, and the like. Further, the threat DB 243 includes information such as assumed threats, perpetrators, security requirements, assumed failures, and attack routes. Sample data of the threat DB 243 is shown in FIG.

The countermeasure DB 244 stores the types of threats assumed for the product, their security requirements, the contents of corresponding countermeasures, and the like. The countermeasure DB 244 includes information such as assumed threats, security requirements, and security function candidates. Sample data of the countermeasure DB 244 is shown in FIG.

The vulnerability information DB 245 stores vulnerabilities, CWE (Common Weakness Enumeration) classifications, corresponding signatures, etc. related to software constituting products. The vulnerability information DB 245 includes the vulnerability title, software type, last update date, countermeasure, CWE, signature installation status, and corresponding signature number. Sample data of the vulnerability information DB 245 is shown in FIG.

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

The project DB 247 stores logs of abnormal and normal test results obtained in system tests, equipment on assumed trust boundaries, etc. in a product development project. Further, the project DB 247 includes information on the project ID, unit name, product code, software type, product group, test log number (normal), test log number (abnormal), and equipment on the reliability boundary. Sample data of the project DB 247 is shown in FIG.

The specification/design document DB 248 shows the traceability of security-related requirements, requests, and design documents, and is composed of information on the correspondence among the requirements, requirements, and external design documents. Sample data of the specification/design document DB 248 is shown in FIG.

The security standard DB 249 stores names of security standards that products generally comply with, and names of standards that products additionally comply with for each individual project. Further, the security standard DB 249 is composed of information such as type and standard name. Sample data of the security standard DB 249 is shown in FIG.

The laws and regulations DB250 shows what security-related laws and regulations are applied to products in domestic and overseas regional categories. Further, the laws and regulations DB 250 includes information such as regional classification, names of laws and regulations, and product groups. Sample data of the laws and regulations DB 250 is shown in FIG.

The security requirement prediction model storage DB 220 stores the security requirement prediction model that has been generated by the security requirement prediction model generation unit 105 and has been trained through supervised learning.

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

Display device 500 displays character strings and images according to user operations. The display device 500 is configured with a liquid crystal display, an organic EL (Electro Luminescence) display, or the like. Note that the display device 500 may be configured integrally with the development-side security analysis support device 10.

The input/output device 600 includes a keyboard, a mouse, a numeric keypad, and the like. A 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 disposed integrally with the display device 500 and is capable of accepting touch operations from a user. Note that the input/output device 600 may be configured integrally 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 implemented using a communication chip, 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 section centered on a security requirement prediction model generation section 105 and a design information selection model generation section 107, a security requirement inference section 109, and a security function inference section. It is roughly divided into an inference section centered on a section 112.

Note that the learning section and the inference section are used to learn the security requirements of the target product and the output of security requirement function selection, but for example, they are connected to the target product via a network and are connected to the target product separately from the target product. It may be a device. Furthermore, the learning section and the inference section may be built into the target product. Furthermore, the learning section and the inference section may reside on a 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 of 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, for example, according to a neural network model. Here, supervised learning refers to a method in which a set of input and result (label) data is given to the learning unit, thereby learning features in the learning data 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 a three-layer neural network as shown in Figure 17, when multiple inputs are input to the input layer (X1-X3), the values are multiplied by weights W1 (w11-w16) and Y1-Y2), and the result is further multiplied by weight W2 (w21-w26) and output from the output layer (Z1-Z3). This output result changes depending on the values of weights W1 and W2.

In this disclosure, learning is performed in the following two neural network models. The first neural network is based on the input data (product features, required specifications (specifications including system configuration diagram), applicable laws and regulations, and security standards) acquired by the security requirement extraction data acquisition preprocessing unit 104. , and outputs are learned by so-called supervised learning according to training data created based on a combination of inputs (security requirements (threats, trust boundaries, responsibility boundaries)) that are the corresponding correct answers.

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

That is, the neural network learns by adjusting the weights W1 and W2 so that input data is input to the input layer and 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 perform the learning described above to generate and output learned models (security requirement prediction model, design information selection model).

<2. Operation＞
Next, the operations of the learning section and inference section of the development side security analysis support device 10 configured as above will be explained 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 accumulation in the learning section. The operation of the learning section will be described below with reference to the flowcharts shown in FIGS. 18 and 19.

In step S101, the data collection unit 101 collects existing data such as past project data 601, vulnerability analysis result information 602, specifications/design documents 603, laws and regulations information 604, security standards 605, past products on the market, etc. The operation log and incident signature information 606 are collected and sent to the data lake 210.

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

If it is text data, in step S106, parsing is performed using natural language processing, and the required specifications of the product plan are extracted from the result. If the data is not text data, that is, if it is image data, etc., image recognition processing is performed on the system configuration diagram in step S107, and the system configuration and confidence boundary are identified from the results.

In step S108, the multimodal feature analysis unit 102 receives the processing results in steps S106 and S107, and combines the natural language processing and image recognition results to determine product specifications according to the system configuration, applicable laws and regulations. Organize the characteristics and relationships of standards, threats, trust boundaries, responsibility boundaries, costs, periods, failure classifications, countermeasures, attackers, attack routes, failure information, operational information, and signatures.

In step S109, the data primary processing integration unit 103 unifies the data into a JSON format. In step S110, the data primary processing and integration unit 103 checks and cleanses the data, and deletes confidential information and unnecessary characters from the syntactic analysis result of natural language processing.

In step S111, the data primary processing integration unit 103 converts all data into CSV format. In step S112, the integrated DH 240 stores a system characteristics 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 DB 248, a security standard DB 249, and a laws/regulations DB 250. Store data to.

<2-1-2. Security requirement prediction model generation step>
FIG. 20 is a flowchart regarding the learning process of the security requirement prediction model in the learning unit. The operation of the learning section will be described below with reference to the flowchart shown in FIG.

In step S201, the security requirement extraction data acquisition preprocessing unit 104 inputs product features, required specifications, applicable laws and regulations, and security standards, and security requirements (threat, trust boundary, responsibility) that serve as the correct label for the input. Obtain training data that shows the correspondence relationship with (demarcation) and prepare for machine learning preprocessing.

In step S202, the security request extraction data acquisition preprocessing unit 104 preprocesses the prepared data so that it can be subjected to machine learning. In step S203, the security requirement prediction model generation unit 105 performs supervised learning using the preprocessed teacher data to generate a model that predicts security requirements (threats, trust boundaries, and responsibility boundaries). In step S204, the security requirement 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 regarding the learning process of the design information selection model in the learning section. The operation of the learning section will be described below with reference to the flowchart shown in FIG.

In step S301, the security function selection data acquisition preprocessing unit 106 selects security requirements (threat, trust boundary, demarcation of responsibility, cost, schedule) and the security function that is the correct label for the security requirement (fault classification, countermeasure, Obtain training data that shows the correspondence with attackers and attack routes) and prepare for machine learning preprocessing.

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

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

<2-2. Reasoning phase>
FIG. 22 is a flowchart regarding inference processing by the inference section. The operation of the inference section will be described below with reference to the flowchart shown in FIG.

In step S401, the product planning data acquisition unit 108 acquires a feature confirmation sheet 653 of the product to be developed inputted by the developer via the input/output device 600, compliant laws/regulations and standards 651, and required specifications (including system configuration diagrams). Specifications) 652 is obtained.

In step S402, the product planning data acquisition unit 108 collects the characteristics of the data in the characteristic confirmation sheet 653 of the acquired product to be developed, the compliant laws, regulations, and standards 651, and the required specifications 652, and Input to the request inference unit 109.

In step S403, the security requirements inference unit 109 uses the characteristics of the product to be developed, requirement specifications (specifications including system configuration diagrams), applicable laws and regulations, and security standards as input, and performs multimodal inference using the supervised learning model. (performs inference using a security requirement prediction model) and outputs the security requirements (threats, trust boundaries, demarcation of responsibility) to be developed. In addition, in the inference in the security requirement prediction model, in order to classify security requirements for assumed threats, system characteristics DB 241, failure DB 242, threat DB 243, project DB 247, specifications/design DB 248, security standards DB 249, laws and regulations are used. Refer to DB250.

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 product to be developed, and outputs the security requirements information sheet 654 for the product to be developed. An example of the security requirement information sheet 654 is shown in FIGS. 23 and 24.

In step S405, the security requirements acquisition unit 111 acquires the data of the security requirements information sheet 654 of the product to be developed, which is the security requirements of the product to be developed 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 inputs the security requirements of the product to be developed according to the cost and schedule, performs inference using the design information selection model, and makes a recommendation for the security function corresponding to the security requirements for the development target. A product security design information sheet 655 is output. In addition, in the inference in the design information selection model, the countermeasure DB 244 is referred to in order to classify the correspondence of function candidates corresponding to the security requirements for the assumed threat. An example of the security design information sheet 655 is shown in FIG.

<3. Effect>
According to the first embodiment, the development side security analysis support device 10 automatically performs "function selection" in addition to "requirement extraction" regarding security analysis at the system level. This has the effect of shortening the time required for security analysis of known threats before product shipment, making it possible to efficiently improve security quality without relying on individual personnel. That is, it becomes possible to efficiently improve the quality of security.

<Embodiment 2>
The development side security analysis support device 10 described in the first embodiment generates the security design information sheet 655 and the like for the product to be developed, and ends its operation. The operation side security analysis support device 50 described in the second embodiment trains a security monitoring model based on the vulnerability information and operation log data stored in the vulnerability information DB 245 and the operation log/signature DB 246. . Then, abnormalities are detected from the operation log of the product in the actual market (product to be operated), and the IPS signature of the product on the operating side is updated, as well as the details of threats and countermeasures on the developer side.

<1. Configuration>
FIG. 26 is a block diagram showing the 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 is a development side security analysis device that analyzes operation logs after product development is completed and is shipped to the market, determines abnormalities, updates signatures, and performs security analysis on products to be developed from now on. Provide 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, a communication unit 1100 that communicates with the product 90 (field), and a processor 800. Further, the operation side security analysis support device 50 is connected to a display device 1200 and an input/output device 1300. The operation side security analysis support device 50 is, for example, a personal computer.

Processor 800 is connected to other hardware via signal lines. The processor 800 can be implemented using a central processing unit (CPU), MPU, DSP, GPU, microcomputer, FPGA, ASIC, or the like. The processor 800 implements various functions by reading the OS, application programs, and various data stored in the auxiliary storage unit 1000, which will be described later, and performing arithmetic processing. Processor 800 includes a functional configuration described below. The functional configuration may be realized by firmware. The hardware that includes the processor 800, a main memory section 900, and an auxiliary memory section 1000, which will be described later, is also referred to as a "processing circuitry."

Main storage section 900 is a volatile storage section. The main storage unit 900 can be implemented using a RAM or the like. The main storage unit 900 is used in the operation-side security analysis support device 50 to temporarily store data that is 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 operation/maintenance analysis log data stored in the operation/maintenance analysis DB 1002.

The operation log data preprocessing unit 902 performs preprocessing for data conversion so that machine learning can be performed on the operation log data.

The security monitoring model inference unit 903 receives product information, fault information, and operation information (normal, abnormal) as input, performs inference using a semi-supervised learning model, and calculates fault classification, threats, signatures, countermeasures, and attackers of fault abnormality data. , output the attack route.

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

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

Auxiliary storage unit 1000 is a nonvolatile storage unit. The auxiliary storage unit 1000 can be implemented using a ROM, HDD, flash memory, or the like. Auxiliary storage unit 1000 stores an OS, application programs, and various data. At least a portion of the OS is loaded into main storage 900 and executed by processor 800.

The auxiliary storage unit 1000 includes a security monitoring model storage DB 1001 that stores security monitoring models generated based on semi-supervised machine 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 generated by the security monitoring model generation unit 114 and learned by semi-supervised learning.

The operation/maintenance analysis DB 1002 includes information such as log numbers, product serial numbers, product codes, supported signature numbers, log acquisition dates and times, failure information, and operation information. Sample data of the operation/maintenance analysis DB 1002 is shown in FIG.

The display device 1200 displays character strings and images according to operations by an operation/maintenance person. The display device 1200 is configured with a liquid crystal display, an organic EL display, or the like. Note that the display device 1200 may be configured integrally with the operation-side security analysis support device 50.

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

The communication unit 700 transmits and receives various data between the operating 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 implemented using a communication chip, NIC, or the like.

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

Note that the learning section and the inference section are used to learn the security requirements of the target product and the output of security requirement function selection, but for example, they are connected to the target product via a network and are connected to the target product separately from the target product. It may be a device. Furthermore, the learning section and the inference section may be built into the target product. Furthermore, the learning section and the inference section may reside on a cloud server.

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

The security monitoring model generation unit 114 performs learning to output by so-called semi-supervised learning, for example, according to a neural network model. Here, semi-supervised learning refers to a method in which a set of input and result (label) data is given to a learning device to learn features in the learning data and infer results 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 a three-layer neural network as shown in Figure 17, when multiple inputs are input to the input layer (X1-X3), the values are multiplied by weights W1 (w11-w16) and Y1-Y2), and the result is further multiplied by weight W2 (w21-w26) and output from the output layer (Z1-Z3). This output result changes depending on the values of weights W1 and W2.

In this disclosure, learning is performed in the following neural network model. The neural network inputs input data (product information, fault information, operation information (normal, abnormal)) obtained by the security monitoring data acquisition preprocessing unit 113 and inputs that are the correct answers (fault classification, threat, signature). , countermeasures, attackers, and attack routes), the output is learned through so-called semi-supervised learning.

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

The security monitoring model generation unit 114 generates and outputs a learned model (security monitoring model) by performing the above-described learning.

<2. Operation＞
Next, the operations of the learning section and inference section of the operating side security analysis support device 50 configured as above will be explained 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 section. The operation of the learning section will be described below with reference to the flowchart shown in FIG.

In step S501, the security monitoring data acquisition preprocessing unit 113 inputs product information, failure information, operation information (normal, abnormal), failure classification, threat, signature, countermeasure, attacker, and the correct label for the input. Obtain training data that shows 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 the preprocessed teacher data to generate 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. Reasoning phase>
31 and 32 are flowcharts regarding inference processing by the inference section. The operation of the inference section will be described below with reference to the flowcharts shown in FIGS. 31 and 32.

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

In step S<b>603 , 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 the information to the security monitoring model inference unit 903.

In step S605, the security monitoring model inference unit 903 uses the product information, fault information, and operation information (normal, abnormal) as input, performs inference using a semi-supervised learning model, and performs fault classification, threat, signature, and countermeasures for the abnormal data. , the attacker, and the attack route are 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 examples of the knowledge file are 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 the 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 10 receives the failure classification, threat, signature, countermeasure, attacker, and attack route of the abnormal data, and transfers the data to the threat/countermeasure comparison and coordination update unit 115. do.

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

Note that if there is an abnormality in the log data after the processing in step S605, in step S609, the signature data comparison unit 904 compares it with the currently registered signature data, creates a signature update list file 1302, and updates the signature information. 905. Note that if the signature is not registered, a request is made to the product's IDS (Intrusion Detection System) to register it.

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

<3. Effect>
According to the second embodiment, during operation after product shipment, 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 understanding the signs of attacks against unknown threats and vulnerabilities after the product is shipped, it is possible to quickly detect unauthorized access and quickly provide feedback to the security analysis support device 10 on the developer side. 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 becomes possible to efficiently improve the quality of security.

<Embodiment 3>
The operation-side security analysis support device 50 described in the second embodiment creates the signature update list file 1302 if there is an abnormality in the log data after the process in step S605. The operation-side security analysis support device 50 described in the third embodiment creates an alert rule update list file 1303 when there is an abnormality in the log data after the process in step S605.

<1. Configuration>
FIG. 35 is a block diagram showing details of the configuration of the operation-side security analysis support device 50 according to the third embodiment. When comparing the operating side security analysis support device 50 according to the second embodiment shown in FIG. 26 and the operating side security analysis support device 50 according to the third embodiment shown in FIG. In this case, the anomaly detection data comparison section 906 is used, and the signature information updating section 905 in FIG. 26 is replaced with the alert rule information updating section 907 in FIG. The rest of the configuration is the same as the operation-side security analysis support device 50 according to the second embodiment, so a detailed explanation will be omitted here.

<2. Operation>
FIG. 36 is a flowchart showing inference processing in the inference unit according to the third embodiment. Note that the operation of the connection source "C" shown in FIG. 36 is similar to the flowchart shown in FIG. 31 (steps S601 to S608) described in the second embodiment. However, in step S606 of FIG. 31, it is necessary to read "signature data comparison section" as "abnormality detection comparison section". Below, steps S701 to S703 shown in FIG. 36 will be explained.

If there is an abnormality in the log data after the processing in step S605, in step S701, the abnormality detection data comparison unit 906 compares the currently registered signature data and the normal log, and creates an alert rule update list file 1303. and transmits it to the alert rule information update unit 907.

In step S702, the alert rule information update unit 907 issues a command to update the signature update data and the rule for detecting an abnormality (hereinafter referred to as "alert rule").

In step S703, the issued signature update data and alert rule update command and data are transmitted to the centralized controller 2004 of the product that serves as a security trust boundary.

<3. Effect>
According to the third embodiment, in addition to the effects of the second embodiment, an alert rule update command can be quickly fed back to the development side security analysis support device 10 when there is an abnormality in the log data. Therefore, the effect of mutual cooperation between the development side security analysis support device 10 and the operation side security analysis support device 50 can be achieved. That is, it becomes possible to efficiently improve the quality of security.

<Embodiment 4>
The development side security analysis support device 10 described in the first embodiment generates the security design information sheet 655 and the like for the product to be developed, and ends its operation. In the development-side security analysis support device 10 described in Embodiment 4, the test section generates a security test model from information on threats, vulnerabilities, security test test cases, test data, security measures, and operation logs obtained from the learning section. Learn and generate. Then, the testing department uses the security test model based on the security design information of the product to be developed (the security design information sheet 655 of the product to be developed) generated by the inference part to predict and predict the judgment results of the security test. Repeatedly generate exploratory test cases that are likely to detect vulnerabilities.

<1. Configuration>
FIG. 37 is a block diagram showing the configuration of the development side security analysis support device 10 according to the fourth embodiment. FIG. 38 is a block diagram showing details of the test section in the development side security analysis support device 10. The test section is included in the inference section. Note that the configurations of the learning section and the inference section in the development side security analysis support device 10 are the same as in the first embodiment except for the integrated HD 240. As shown in FIG. 39, the integrated HD 240 includes a security test/alert rule DB 251. Sample data of the security test/alert rule DB 251 is shown in FIG.

The security test data acquisition preprocessing unit 116 acquires information on threats, vulnerabilities, security test test cases, test data, security measures, and operation logs from the integrated HD 240 of the learning unit, and performs machine learning on these data. Preprocess.

The security test model generation unit 117 (third model generation unit) utilizes machine learning using preprocessed data to generate security tests based on attack models (generating and implementing test cases) and defense models (implementing security measures). Generate a model to test. Regarding machine learning, for example, reinforcement learning is applied to generate attack models and defense models. In reinforcement learning, an agent (actor) in a certain environment observes the current state (parameters of the environment) and decides what action to take. The environment changes dynamically depending on the actions of the agent, and the agent is rewarded according to changes in the environment. The agent repeats this process and learns the course of action that yields the most rewards through a series of actions.

The security test reward calculation unit 118 cooperates with the security test model generation unit 117 including the security test function update unit 123 when generating a trained model by reinforcement learning. The reward is calculated based on criteria such that if the attack is successful, the reward is increased, and if the defense is successful, the reward is decreased.

The security test determination data acquisition unit 119 acquires information necessary for reward calculation and information for comparing whether threats and countermeasures are known from the security test determination result 656 by the security test model inference unit 122. Sample data of the security test determination result 656 is shown in FIG.

The security design information acquisition unit 120 acquires design information data (security design information sheet 655 of the development target product) corresponding to the security requirements of the development target product according to the cost and schedule, and sends it to the security test input/output observation unit 121. Input data.

The security test input/output observation unit 121 determines test conditions such as trust boundaries and operation logs (test results) from the product information, security requirements, demarcation of responsibility, security design information of the product, and security test judgment results 656 that are fed back. It generates vulnerability information that is the corresponding state, security test cases and test data based on threats that serve as input for the attack model, and security measures based on the security functions of the defense model.

The security test model inference unit 122 utilizes a predetermined test suite and outputs a security test determination result by predicting an output result from past determination results for test cases of the security test.

The security test function update unit 123 is included in the security test model generation unit 117 and updates the function for determining the predicted output of test case generation and test judgment results according to the reward calculated by the security test reward calculation unit 118. . Then, the updated function is output to the security test model storage DB 260. For example, in the case of Q-learning, an action value function Q (s _t , a _t ) expressed by the following equation (1) is used as a function for predicting a judgment result for a test case and calculating its output.

<2. Operation>
42 and 43 are flowcharts showing data acquisition, security test model generation, and inference processing in the test section. The operation of the test section will be described below with reference to the flowcharts shown in FIGS. 42 and 43.

<2-1. Learning phase>
<2-1-1. Data acquisition step＞
In step S801, the security test data acquisition preprocessing unit 116 stores threats in the threat DB 243 of the integrated DH 240, vulnerabilities in the vulnerability information DB 245, security test cases and test data in the security test/alert rule DB 251, security measures in the countermeasure DB 244, Each operation log of the operation log signature DB 246 is acquired.

In step S802, the security test data acquisition preprocessing unit 116 performs preprocessing such as data cleansing so that machine learning can be performed on the acquired data.

<2-1-2. Security test model generation step>
In step S803, the security test model generation unit 117 uses the preprocessed data to generate, through reinforcement learning, a model that performs a security test for generating exploratory test cases and predicting test determination results. In other words, the test case that corresponds to the security measures, vulnerabilities, and threats in question is used as input, the predicted result of the test case is obtained as output, and a test case that can detect more vulnerabilities is generated to predict the test result. Execute iteratively and repeatedly.

Q-learning and TD-learning are known as typical methods of reinforcement learning. For example, in the case of Q-learning, a general updating formula for the action value function Q(s, a) is expressed by equation (1).

In equation (1), s _t represents the state of the environment at time t, and a _t represents the behavior at time t. The action a _t changes the state to s _t+1 . r _t+1 represents the reward obtained by changing the state, γ represents the discount rate, and α represents the learning coefficient. Note that γ is in the range of 0<γ≦1, and α is in the range of 0<α≦1. The generation of test cases for normal operations and abnormal operations and their implementation become actions a _t , and the operation logs and predicted test results for test cases for normal operations and abnormal operations, known and unknown vulnerabilities and threats become states s _t . , learn the best action a _t in state s _t at time t.

The update formula expressed by equation (1) is such that if the action value Q of action a with the highest Q value at time t+1 is greater than the action value Q of action a executed at time t, the action value Q is increased. However, in the opposite case, the action value Q is decreased. In other words, the action value function Q(s, a) is updated so that the action value Q of action a at time t approaches the best action value at time t+1. As a result, the best action value in a certain environment will be successively propagated to the action value in the previous environment.

In step S804, the security test model generation unit 117 repeatedly performs learning such as steps 801 to 803, step 805, and steps 806 to 809. The security test model storage DB 260 stores the action value function Q(s _t , a _t ) updated by the security test function update unit 123, that is, the learned security test model.

In step S805, the security test reward calculation unit 118 increases the reward of the security test model (for example, gives a reward of "1") if the attack is successful. On the other hand, if the defense is successful, the reward of the security test model is decreased (for example, a reward of "-1" is given). The calculation of such remuneration is based on the following criteria (remuneration standards). In other words, the reward of the security test model is based on test case generation and execution for normal operations and abnormal operations (actions), operation logs for test cases and prediction of test results, known and unknown vulnerabilities and threats (state). is calculated.

<2-2. Reasoning phase>
In step S806, the security design information acquisition unit 120 acquires design information data (security design information sheet 655 of the development target product) corresponding to the security requirements of the development target product according to the cost and schedule, and security test input/output Data is input to the observation unit 121.

In step S807, the security test input/output observation unit 121 collects information such as trust boundaries, operation logs (test results), etc. from the product information, security requirements, demarcation of responsibility, security design information, and security test judgment results 656 that are fed back. Observe vulnerability information that corresponds to the test conditions, security test cases and test data based on threats that serve as input for the security test model, and the predicted results of the tests.

In step S808, the security test model inference unit 122 predicts and outputs the security test determination result 656 based on the test results using the test suite of the product. Inputting test cases corresponding to threats and their countermeasures learned through reinforcement learning, and using learned models stored in the security test model storage DB 260, predicted logs and test results are inferred. Note that the predicted logs and security test results are fed back to step S807 so that they can be referenced in sequential security test inferences.

In the fourth embodiment, a case has been described in which reinforcement learning is applied to the learning algorithm used by the security test model inference unit 122, but the present invention is not limited to this. As for the learning algorithm, in addition to reinforcement learning, it is also possible to apply adversarial inverse reinforcement learning and the like.

In step S809, the security test determination data acquisition unit 119 acquires, from the security test determination result 656, information necessary for reward calculation and information for comparing whether threats and countermeasures are known. The acquired information is transmitted to the security test reward calculation unit 118 and the threat/countermeasure comparison/coordination update unit 115 as feedback for successive security tests.

In step S810, the threat/countermeasure comparison/coordination update unit 115 updates the information in the integrated DH 240 if there is unknown content in the failure classification, threat, signature, countermeasure, attacker, or attack route of the abnormal data. do.

In step S811, if there is data to be updated, the integrated DH 240 updates the corresponding DBs such as system characteristics DB 241, failure DB 242, threat DB 243, countermeasure DB 244, vulnerability information DB 245, operation log/signature DB 246, project DB 247, and specifications. The data is stored in the document/design document DB 248, security standard DB 249, law/regulation DB 250, and security test/alert rule DB 251.

<3. Effect>
According to the fourth embodiment, in the development side security analysis support device 10, the learning section, the inference section, and the testing section can cooperate with each other in the product development process, so that product development that requires high quality products is possible. can be carried out efficiently. In addition, by utilizing machine learning such as reinforcement learning in the testing department, test results based on test cases that address not only known vulnerabilities and threats but also unknown vulnerabilities and threats can be compared with past test results. Predict from actual data. This allows you to understand the necessary measures and mutually strengthen security in product development and operation.

Note that within the scope of the present disclosure, it is possible to freely combine the embodiments, or to modify or omit each embodiment as appropriate.

Although the present disclosure has been described in detail, the above description is in all aspects illustrative and not restrictive. It is understood that countless variations not illustrated may be envisioned.

10 Development side security analysis support device, 50 Operation side security analysis support device, 90 Product, 100 Main storage unit, 101 Data collection unit, 102 Multimodal feature analysis unit, 103 Data primary processing integration unit, 104 Before acquiring security request extraction data Processing unit, 105 Security requirement 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 requirement inference unit, 110 Cost/schedule adjustment unit, 111 Security requirements 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 and coordination update unit, 116 Security test data acquisition pre-processing unit, 117 Security test model generation 118 Security test reward calculation unit, 119 Security test judgment data acquisition unit, 120 Security design information acquisition unit, 121 Security test input/output observation unit, 122 Security test model inference unit, 123 Security test function update unit, 200 Auxiliary storage unit , 210 Data lake, 220 Security requirement prediction model storage DB, 230 Design information selection model storage DB, 240 Integrated DH, 241 System characteristics DB, 242 Failure DB, 243 Threat DB, 244 Countermeasures DB, 245 Vulnerability information DB, 246 Operation Log/Signature DB, 247 Project DB, 248 Specification/Design DB, 249 Security Standard DB, 250 Law/Regulation DB, 251 Security Test/Alert Rule DB, 260 Security Test Model Storage DB, 300 Interface Unit, 400 Processor, 500 Display device, 600 Input/output device, 601 Past project data, 602 Vulnerability analysis results, 603 Specifications and design documents, 604 Laws and regulations information, 605 Security standards, 606 Operation logs and incident information of products in past markets Signature information, 651 Compliant laws, regulations, and security standards, 652 Required specifications for the product to be developed, 653 Feature confirmation sheet for the product to be developed, 654 Security requirements information sheet for the product to be developed, 655 Security design information sheet for the product to be developed, 656 Security test judgment result, 700 Communication unit, 800 Processor, 900 Main storage unit, 901 Operation log data acquisition unit, 902 Operation log data preprocessing unit, 903 Security monitoring model inference unit, 904 Signature data comparison unit, 905 Signature information update Department, 906 Anomaly Detection Data Comparison Department, 907 Alert Rule Information Update Department, 1000 Auxiliary Storage Department, 1001 Security Monitoring Model Storage DB, 1002 Operation/Maintenance Analysis DB, 1100 Communication Department, 1301 Knowledge File Obtained from Operation of Products in the Market , 1302 Signature update list file, 1303 Alert rule 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 (7)

Data including characteristics of the development target, requirement specifications of the development target, and predetermined regulations to which the development target complies is input into a security requirement prediction model for predicting security requirements that match the development target. a 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 storing information indicating correspondence between security requirements and security requirements, based on the security requirements inferred by the security requirement inference unit; and,
a security function inference unit that inputs the security requirements acquired by the security requirement acquisition unit into a design information selection model for selecting design information that realizes a security function suitable for the development target, and infers the design information; ,
Development side security analysis support device equipped with. Information about threats to the development target stored in a data warehouse and countermeasures against the threat includes characteristics of the development target, required specifications of the development target, and predetermined regulations to which the development target complies. A first method that generates the security request prediction model that predicts the security request that matches the development target by learning a first input and the security request that is a correct answer label for the first input as training data. a model generation unit,
By learning the second input consisting of the security requirements included in the information stored in the data warehouse and the selection of the security function that is the correct answer label for the second input as training data, the development target a second model generation unit that generates the design information selection model that selects the design information for;
The development side security analysis support device according to claim 1, comprising: Reinforcement learning is performed using learning data including a state consisting of the design information, operation log, and vulnerability information, and a third input consisting of a security test case included in information stored in a data warehouse for the state. 3. The method according to claim 1, further comprising a third model generation unit that generates a security test model that exploratoryly outputs a security test case for the development target based on a reward standard for a predicted test result. Development side security analysis support device. 4. The development side security analysis support device according to claim 1, wherein the required specifications include a system configuration diagram. The development side security analysis support device according to any one of claims 1 to 4, wherein the security request includes a threat, a trust boundary, and a demarcation of responsibility. 6. The development side security analysis support device according to claim 1, wherein the design information includes a failure classification, a countermeasure, an attacker, and an attack route. A development side security analysis support device according to any one of claims 1 to 6;
An operation side security analysis support device,
Equipped with
The operation side security analysis support device includes:
an anomaly detection data comparison unit that obtains signatures and alert rules and issues commands to update the signatures and alert rules;
a communication unit that receives operation log information including operation information, product information, and failure information of the operation target to which the signature and alert rule updated by the anomaly detection data comparison unit are applied, and stores the received operation log information in an operation and maintenance analysis database;
an operation log data acquisition unit that acquires the operation log information from the operation and maintenance analysis database;
The operation log information acquired by the operation log data acquisition unit is input into a trained security monitoring model that has undergone machine learning to predict knowledge information obtained from the operation of the operation target product in the market, and the security monitoring a security monitoring model inference unit that predicts the knowledge information by performing arithmetic processing using the model;
Equipped with
A security analysis support system in which the development-side security analysis support device and the operation-side security analysis support device cooperate with each other to provide security-related information in a mutually complementary manner.

Images