Trust management device and trust management method

Abstract

To provide a mechanism for collecting and evaluating information for determining trust by a method for minimizing the influence on the operation of an ICS.SOLUTION: A trust management device according to the present invention generates, from design information or operation information on a system, an expected specification in which the system expects from an entity as a system component, and collects information to be compared with the expected specification and related to an entity detected by the system from the detected entity by a method in which the influence on the system is small enough to meet predetermined criteria.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] The present invention relates to a trust management device and a trust management method. [Background technology]

[0002] Recently, the use of open technologies in industrial control systems (ICS) has become more widespread, but at the same time, cybersecurity issues have become more serious. For example, as more and more Internet of Things (IoT) devices are introduced into ICS, the sources of attack are diversifying, with malicious software infiltrating ICS via IoT devices and malicious software being installed on each device within the ICS via the supply chain. Meanwhile, in order to promote ICS digital transformation (DX), it is essential to ensure scalability so that diverse technologies can be flexibly incorporated. Therefore, even in ICS, it is important to implement security measures that assume intrusions will occur.

[0003] Additionally, security measures based on the idea of ​​zero trust are beginning to take hold, particularly in the information systems of enterprises (large corporations). These measures are based on the idea of ​​"designing security defenses on the assumption that malicious software has infiltrated the system network," rather than the traditional perimeter defense approach, and involve strengthening security at endpoints and implementing strict access control policy management.

[0004] However, unlike enterprise information systems, ICS has the disadvantages of having poor embedded computer processing performance and being replaced or updated less frequently than enterprise systems. For these reasons, there are still challenges in applying zero trust architecture to ICS as is. Therefore, it is difficult to implement verification and control for security measures at all endpoints, and it is necessary to realize a trust management architecture suitable for ICS while taking these challenges into account.

[0005] To achieve trust management, it is necessary to clarify the definition of "trust" in ICS and to establish a mechanism to maximize the evaluation of trust in ICS while minimizing the impact on ICS.

[0006] The technology of Patent Document 1 can determine whether to allow a client platform to access resources or services on a network based on multiple pieces of integrity information received from the client platform before allowing the client platform to access those resources or services on the network. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Special Publication No. 2009-518762 [Non-patent literature]

[0008] [Non-Patent Document 1] ISO / IEC TR 24028:2020(E),p6,3.42 Summary of the Invention [Problem to be solved by the invention]

[0009] According to Patent Document 1, whether to grant access can be determined based on multiple pieces of integrity information received from a client platform. However, the integrity information used to determine trust must be defined individually, and a database of optimized trust criteria must be prepared for each ICS. Furthermore, as the ICS becomes more complex due to the use of open technology, the trust criteria to be stored in the database tend to become more complex, making it necessary to carefully select criteria that are meaningful for the ICS.

[0010] Non-Patent Document 1 defines trustworthiness as "the ability to meet stakeholders' expectations in a verifiable way." Following this definition, it is also possible to define "trust" as demonstrating or verifying in a measurable way that the properties expected by stakeholders (ICS) are met. However, in this case, it is necessary to carefully select the requirements for the ICS, such as system design specifications and operating conditions, and Patent Document 1 does not take this into consideration sufficiently.

[0011] Furthermore, when collecting information to determine trust, there are cases where the information that can be collected from the client is limited. For example, there are many cases where an information collection agent cannot be installed on the client, or where ICS cannot collect information by verifying responses after sending various communication data to the target device.

[0012] Therefore, an object of the present invention is to provide a mechanism for collecting and evaluating information for determining trust in an ICS in a way that minimizes the impact on ICS operation, while taking into account trust in the ICS, which could not be resolved by these conventional technologies. [Means for solving the problem]

[0013] The trust management device of the present invention generates expected specifications that the system expects from entities as system components from system design information or operation information, and collects information on entities detected by the system, which is information for comparison with the expected specifications, from the detected entities in a way that minimizes the impact on the system to a degree that meets a predetermined standard. storing measurable criteria for each of the plurality of expected specifications, evaluating the degree to which the detected entity satisfies the expected specifications using qualitative or quantitative indicators based on the criteria, and obtaining or tracking information on which the criteria are based; It is characterized by:

[0014] In this invention, trust is defined as the ability to verify, in a demonstrable, verifiable, or measurable manner, that elements (entities) involved in the information processing and operation of a system (ICS), such as devices, users, subsystems, and software, satisfy the specifications that the system should have. Here, the specifications that the system should have are the design specifications of the target system and the conditions for system operation.

[0015] In other words, the system (ICS) as a whole expects certain specifications from the individual entities that make up the system. Here, entities include those that the system has already accessed and those that it has not yet accessed. The specifications that the system expects from entities are also called "expected specifications," and are distinguished from the specifications that the entities actually possess (information about the entities). Of course, the information that the entities actually possess can be compared with the expected specifications.

[0016] Here, the system design specifications refer to system design information including a system requirements specification including non-functional requirements, and a system configuration specification such as system network information and device configuration.

[0017] For example, suppose a non-functional requirement of a system network is that "encrypted communication is possible between nodes participating in the network." In this case, the trust relationship between the entity and the system is satisfied only when the entity participating in the network proves that it can perform encrypted communication, or when the system verifies this. This system requirement can be cited from the system design document or individually defined by the system administrator.

[0018] Furthermore, system operation information consists of information about the system operation, such as the environment in which the system is located, operation manuals for system users, etc. For example, if a system handles safety control functions of important control processes using applications, the importance of the applications handled by the system (the severity of problems when they occur) is an example of the environment in which the system is located.

[0019] The present invention is a trust management device and a trust management method characterized in that specifications (expected specifications) that a system expects from an entity are generated from the system design information and system operation information described above.

[0020] Furthermore, the present invention makes it possible to observe the system's operating status and collect the maximum amount of information necessary to determine the trust while minimizing the impact on the system (ICS).The method of this invention is characterized by observing and evaluating the system's operating status and device characteristics, and scheduling information collection means based on the observation and evaluation results and expected specifications. [Effects of the Invention]

[0021] According to the present invention, it is possible to provide a mechanism for collecting and evaluating information for determining trust in an ICS, in a way that minimizes the impact on the operation of the ICS. [Brief explanation of the drawings]

[0022] [Figure 1] 1 is a diagram illustrating the overall configuration of the present embodiment. [Figure 2] FIG. 2 is a diagram illustrating an example of a hardware configuration of a trust management device according to the present embodiment. [Figure 3] FIG. 10 is a diagram illustrating the operation of an expected specification generation process in this embodiment. [Figure 4A] FIG. 2 is a diagram showing an input screen for system design information in the present embodiment. [Figure 4B] FIG. 10 is a diagram showing an input screen for system operation information in the present embodiment. [Figure 5] FIG. 10 is a diagram showing an input analysis processing flow in the present embodiment. [Figure 6] FIG. 10 is a diagram showing an expected specification generation processing flow in the present embodiment. [Figure 7] FIG. 10 is a diagram showing a list of expected specifications in the present embodiment. [Figure 8] FIG. 10 is a diagram showing a trust level determination criteria table in the present embodiment. [Figure 9] 10A and 10B are diagrams illustrating an information scan control operation in the present embodiment. [Figure 10] FIG. 10 is a diagram illustrating a trust level determination operation in this embodiment. [Figure 11] FIG. 10 is a diagram showing a processing flow when a new entity is detected in this embodiment. [Figure 12] FIG. 10 is a diagram illustrating scan switching timing in the present embodiment. [Figure 13] FIG. 10 is a diagram showing an output of the trust management device in this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0023] <Overall structure> DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

[0024] 1 is a diagram showing the overall configuration of this embodiment. An industrial control system (ICS) 10 is connected to a trust management device 100 via an ICS network 11. The industrial control system (ICS) 10 includes many components (entities) 12 to 16. The trust management device 100 determines whether these components satisfy expected specifications based on the idea of ​​zero trust.

[0025] A trust management device 100 is connected to an ICS network 11. A system component 12 such as a control device is connected to the ICS network 11 and executes business-related processes. Software 12-1 that controls the hardware of the system component 12 is installed in the system component 12 and executes predetermined information processing functions.

[0026] A remote terminal 13 that remotely accesses the trust management device 100 and provides operation processing to a user (system administrator) of the trust management device 100 is also connected to the ICS network 11. The system administrator performs management tasks using the trust management device 100 via the remote terminal 13 or via a local user interface that the trust management device 100 has.

[0027] A monitoring device 14 is connected to the ICS network 11, and monitors and collects the status of computational resources related to the ICS 10, such as the network load and the processing status of each information processing device connected to the ICS 10. The monitoring device 14 corresponds to, for example, an ICS component (control system centralized management function) called SCADA (Supervisory Control And Data Acquisition) or Historian.

[0028] The ICS network 11 is also connected to a scan terminal 15 that collects information related to trust decisions from entities that have newly joined the ICS network 11 and from devices that are already connected to the ICS network 11. The trust management device 100 has the authority to control the scan terminal 15 to collect information or execute a scan process.

[0029] Furthermore, a security control device 16 that executes security control processing specified by the trust management device 100 is connected to the ICS network 11. The security control device 16 executes access control (authentication, authorization, and accounting) of networks and endpoints, such as firewalls and IPS (Intrusion Prevention Systems), according to instructions from the trust management device 100. The security control device 16 executes control processing related to security, such as network separation using VLAN (Virtual Local Area Network) technology and encrypted communication control, according to instructions from the trust management device 100.

[0030] <Hardware configuration> 2 is a diagram showing an example of the hardware configuration of the trust management device in this embodiment. This configuration includes, as elements, a storage unit 101 equivalent to a storage area in a computer, a CPU (Central Processing Unit) 104 that executes calculation processing, a main memory 105 consisting of volatile storage elements into which programs and data are loaded and which holds data for executing calculation processing, a user interface 106 that handles the exchange of data between the computer and the user, and a communication processing unit 107 that handles communication processing between other computers.

[0031] The storage unit 101 includes a program 102 that stores processing information related to trust management and a database 103 that stores data related to trust management. The storage unit 101 corresponds to a nonvolatile storage element such as an HDD (Hard Disk Drive) or an SDD (Solid State Drive), for example.

[0032] The program 102 is software written in a language that can be interpreted by the CPU 104, and executes the functions provided by the trust management device 100. Note that this configuration is not limited to being implemented in physically existing hardware, but may also be implemented in virtualized hardware, and the implementation form of the hardware blocks is not limited to being physically existing hardware.

[0033] The user interface 106 is configured as a command line interface (CLI) or a graphical user interface (GUI) that allows input based on commands, and is user-friendly. The communication processing unit 107 is a network interface card or the like for connecting to the ICS network 11. The communication format may be a wired network or a wireless network.

[0034] <Trust management mechanism in this invention> The trust management mechanism according to the embodiment of the present invention will be described below with reference to the drawings.

[0035] <Mechanism for generating expected specifications in this invention> 3 is a diagram showing the operation of the expected specification generation process in this embodiment. System design information 301 and system operation information 302 are input to the trust management device 100 either manually by the user or via the remote terminal 13, and are accepted by the user interface 106 and communication processing unit 107 of the trust management device 100. In other words, the user inputs the system design information 301 or system operation information 302 as a document in accordance with a predetermined format. The input information is read into the program 102 loaded into the main memory 105 of the trust management device 100.

[0036] The program 102 includes an input information analysis unit 311 and an expected specification generation unit 312. First, the input information analysis unit 311 extracts information necessary for generating the expected specifications of the system. Next, the expected specification generation unit 312 generates the expected specifications based on the input information. The expected specification generation unit 312 references a standard specification DB (Data Base) 313 and extracts additional information necessary for generating the expected specifications.

[0037] The input information analysis unit 311 may generate expected specifications by reading templated input and extracting tagged information, or may extract information necessary for generating expected specifications by performing text mining processing on the system design information 301.

[0038] The expected specifications are generated from the system design information 301 or the system operation information 302, but if the information for generating the expected specifications is insufficient, the expected specifications generation unit 312 references the expected specifications template stored in the standard specification DB 313 to make up for the lack of expected specifications. The expected specifications template can be linked to attribute information on a template-by-template basis, and if the attributes of the trust management target system (ICS10) can be determined from the input information, the template can also be extracted from the attribute information.

[0039] For example, if there is attribute information called "system importance" and the attribute value is made up of "high, medium, low," an expected specification template for the attribute value of "high," an expected specification template for "medium," and an expected specification template for "low" are stored in the standard specification DB 313. The expected specification generation unit 312 determines the "system importance" based on the results of analysis by the input information analysis unit 311, and extracts the corresponding expected specification template.

[0040] 4A is a diagram showing an input screen for system design information in this embodiment. The system design information 301 input fields include fields for inputting document files related to system design, such as a system design document and a system requirement specification, as well as fields for inputting individual system information. Examples of document files include documents (documents that follow a predetermined format) created using document creation software used in OA (Office Automation) operations. Multiple related files can also be input.

[0041] The system information is input separately into network information and asset information of the trust management target system. Examples of network information include the network topology, the type of network (wired LAN, wireless LAN, serial network, etc.), and the connection relationships between nodes participating in the network.

[0042] Network information can be entered by preparing a text-based definition file and inputting this file, or by drawing it on the screen as a GUI. Similarly, asset information can be entered as a text-based definition file or as a GUI. Asset information consists of, for example, asset names, entity types and subcategories, and entity requirement specification definition information for realizing the system.

[0043] 4B is a diagram showing an input screen for system operation information in this embodiment. The system operation information 302 input fields include a field for inputting document files related to system operation, such as a system operation manual, and a field for inputting information related to system operation individually. Examples of document files include documents (documents following a predetermined format) created using document creation software used in OA (Office Automation) operations. Similar to the system design information input shown in FIG. 4A, multiple related files can also be input.

[0044] When entering individual information about system operations, there are individual input items related to system operations and the environment, such as "system application" and "system importance," and the appropriate item is selected. Note that there is also a method of entering the definitions of each of these system operation information items in a text-based definition file. The screens shown in FIGS. 4A and 4B are displayed via the local user interface of the remote terminal 13 or the trust management device 100.

[0045] 5 is a diagram showing the input analysis processing flow in this embodiment. This input analysis processing is executed by the program 102 (input information analysis unit 311) in the trust management device 100.

[0046] In step S501, the input information analysis unit 311 receives the system design information 301 or the system operation information 302 from the user interface 106 or the communication processing unit 107, and then analyzes this input information. At this time, the input information analysis unit 311 extracts information required to build a system structure model and an operation model required to generate expected specifications from the input information.

[0047] In step S502, the input information analysis unit 311 generates a system structure model that is an expected specification based on the input system design information 301. This system structure model is defined as metadata made up of a plurality of pieces of attribute information.

[0048] In step S503, the input information analysis unit 311 generates an operation model based on the input system operation information 302. Like the system structure model, the operation model is also defined as metadata consisting of multiple pieces of attribute information.

[0049] In step S504, the input information analysis unit 311 generates and outputs the system structure model and operation model as structured data. This structured data is generated in a data format that expresses structured data, such as XML (Extensible Markup Language) or JSON (JavaScript Object Notation). This structured data is saved as a file as needed and can be referenced via the user interface 106 or the remote terminal 13.

[0050] 6 is a diagram showing the expected specification generation processing flow in this embodiment. This expected specification generation processing is also executed by the program 102 (expected specification generation unit 312) in the trust management device 100. This processing flow generates expected specifications based on the structured data generated by the processing shown in FIG.

[0051] In step S601, the expected specification generation unit 312 analyzes the structured data and extracts information necessary for generating an expected specification model.

[0052] In step S602, the expected specification generation unit 312 generates an expected specification model from the system structure model and operation model extracted from the structured data. In this process, the expected specification generation unit 312 may generate the expected specification model by directly using the information of the system structure model and operation model, or may generate the expected specification model by referencing the standard specification DB 313 and extracting template expected specifications.

[0053] In step S603, the expected specification generation unit 312 acquires criteria information for evaluating the degree of satisfaction with the expected specifications from the standard specification DB 313 based on the expected specification model.

[0054] In step S604, the expected specification generation unit 312 outputs the expected specifications after successfully acquiring the expected specification model and criteria.

[0055] 7 is a diagram showing an expected specification list in this embodiment. The expected specification list is part of the expected specification template stored in the standard specification DB 313 in FIG. 3, and associates point domains, trust targets, expected specifications, and criteria with each other.

[0056] A point domain is a network or component on a trusted managed system. The trust target is, for example, a list of components connected to the "control information network."

[0057] The expected specifications are defined in the form of system requirements for the trust management target system, such as "supporting strong encryption communication functions (NW-01)." For example, taking the above-mentioned expected specifications as an example, criteria are defined as a means of verifying the expected specifications of a system in a measurable manner, such as "confirming that the system has public key cryptography processing functionality of TLS (Transport Layer Security) v1.3 or higher" or "confirming that the system has symmetric key cryptography functionality equivalent to AES (Advanced encryption standard)."

[0058] Expected specifications may be organized from various perspectives related to trust. For example, expected specifications for an entity may be determined according to characteristics such as authenticity, reliability, protectivity, security, quality, and resilience. However, expected specifications are not limited to the above items.

[0059] Fig. 8 is a diagram showing a trust level determination criteria table in this embodiment. The trust level determination criteria table associates multiple combinations of detailed verification methods and trust levels with combinations of expected specifications and criteria in the expected specifications list in Fig. 7. The trust level determination criteria table is also part of the expected specification templates stored in the standard specification DB 313 in Fig. 3.

[0060] As mentioned above, detailed verification methods are specific means of verifying the defined criteria in a measurable manner. Examples of detailed verification methods include "manual input by a trusted user (authorized to use the system)," "verifying from the software library that the TLS communication library is included (in the target component)," and "verifying the establishment of a TLSv1.3 session by communication capture or active scanning."

[0061] The trust level is a number that indicates the result of verification using the detailed verification method. For example, trust level "1" is specified for "manual input by a trusted user." Trust level "2" is specified for "confirmation from a software library that a TLS communication library is included." Trust level "3" is specified for "confirmation of TLSv1.3 session establishment using communication capture or active scan." The trust level may be a qualitative specification such as level 1 or level 2, or it may be a quantitative ratio such as a percentage indicating the likelihood of the expected specification. The trust level can also be said to be the degree to which an entity fulfills the expected specification.

[0062] 9 is a diagram showing the information scan control operation in this embodiment. The trust management device 100 acquires the system status of the trust management target system from the monitoring device 14 via the communication processing unit 107. This system status includes system operation status information acquired from SCADA, Historian, and log information of each information processing device constituting the system, network processing load status information, processing load status information of the information processing device, etc.

[0063] Using the system state configured from these pieces of information as input information, the system state analysis unit 911 loaded from the program 102 in the trust management device 100 to the main memory 105 executes analysis processing of the system state. As a result of this analysis, the system state analysis unit 911 obtains changes in the processing resources of the system and each information processing device when viewed on a time axis.

[0064] Based on the analysis results and model information of the trust management target system, the information collection scheduler 912 formulates an information collection schedule for evaluating the degree of satisfaction with the expected specifications. The data collection instructing unit 913 generates a data collection instruction based on the information collection schedule formulated by the information collection scheduler 912. The data collection instruction is an instruction to one or more scan terminals 15 participating in the ICS network 11. The data collection instructing unit 913 transmits the data collection instruction to each scan terminal 15 via the communication processing unit 107.

[0065] 10 is a diagram showing the trust level determination operation in this embodiment. Information about the entity to be verified (entity-related data) is input to the trust management device 100 by automatic input from each scanning terminal 15 connected to the ICS network 11 or manual input via the user interface 106.

[0066] The collected data analysis unit 1011 analyzes the input entity-related data. This analysis is performed in a manner that satisfies the detailed verification method specified in FIG. Next, the trust level determination unit 1012 determines the trust level based on the analysis result. The trust level determination unit 1012 determines the trust level based on the degree to which the specified detailed verification method is satisfied, using the trust level determination criteria table in Fig. 8.

[0067] Thereafter, the notification / security control unit 1013 displays the trust level judgment result or determines the security control content.

[0068] The notification and security control unit 1013 notifies the trust level judgment result to the local user interface in the trust management device 100 via the user interface 106, or to the remote terminal 13 via the communication processing unit 107. When executing security control, the notification and security control unit 1013 transmits a security control instruction to each security control device 16 connected to the ICS network 11 via the communication processing unit 107.

[0069] FIG. 11 is a diagram showing a processing flow when a new entity is detected in this embodiment. In step S1101, the collected data analysis unit 1011 detects a new entity joining the ICS network 11 by notification from the scan terminal 15 or manual input from the user.

[0070] In step S1102, each scan terminal 15 executes an information scan on the new entity in accordance with the data collection schedule generated by the information collection scheduler 912. Note that the collected data analysis unit 1011 may detect the existence of the new entity from the log information output by the monitoring device 14.

[0071] In step S1103, the collected data analysis unit 1011 collects and analyzes the obtained scan results. In step S1104, the trust level determination unit 1012 uses the trust level determination criteria table of FIG. 8 to determine the trust level from the analysis results of this information and the expected specifications for the new entity. In step S1105, the trust level determination unit 1012 notifies the system administrator of the trust level of the new entity, or generates a security control instruction and notifies each security control device 16 of it.

[0072] Next, a method for scanning information in this embodiment that minimizes the impact on the ICS will be described.

[0073] Fig. 12 is a diagram showing the timing of scan switching in this embodiment. For example, suppose that the graph shown in Fig. 12 is obtained as a result of monitoring the time change of the network load as a system state by the monitoring device 14. As is generally known, there are two types of scan methods: passive scan, in which communication data is not generated by the device itself, and active scan, in which communication data is generated by the device itself and responses to the data can be observed. The scan terminal 15 switches between these two methods.

[0074] Specifically, for example, at peak times (maximum network load points), the scan terminal 15 refrains from active scanning that generates excessive communication and performs only passive scanning that does not generate excessive communication.The scan terminal 15 performs active scanning when the bandwidth has settled (minimum network load points).

[0075] This makes it possible to collect the maximum amount of information when the system (ICS) is under low load. ICSs often execute predetermined processes periodically, and this method is useful as a means of minimizing the impact on the ICS. Note that the timing for switching scanning methods is not limited to the example above. Another example is JIT (Just-In-Time) scheduling, which dynamically observes the status of the ICS and executes active scanning when the network load is decreasing.

[0076] Furthermore, there is also a method for determining the scanning method according to the attributes of the scan target. For example, the scanning terminal 15 performs active scanning regardless of the timing for host devices with sufficient computing resources, such as industrial personal computers and server equipment. In operation modes such as "maintenance" and "trial operation," the scanning terminal 15 always performs active scanning because there is no impact on business operations that could lead to a system shutdown.

[0077] In FIG. 12, the scanning terminal 15 performs an active scan at a minimum point of the network load, but this is just one example. The monitoring device 14 may monitor changes over time in system states other than the network load. The scanning terminal 15 does not need to perform an active scan only when a given system state is strictly at a minimum value; it may collect information about entities in a way that minimizes the impact on the system to a degree that meets a predetermined standard. The scanning terminal 15 may constantly monitor the slope of the tangent to the network load to determine minimum and maximum points, or may determine these points by machine learning past time-series changes in the network load.

[0078] In other words, in order to reduce the impact on the system, the trust management device 1 generates a scan instruction to selectively perform passive scanning or active scanning on the scanning terminal 15 installed inside the system (ICS) according to the established information collection schedule.

[0079] The trust management device 100 may switch between passive scanning and active scanning depending on the attribute information of the detected entity or the operating state of the system (ICS). For example, suppose there are two scanning terminals 15, and the timing (first timing) when the first scanning terminal becomes available is followed by the timing (second timing) when the second scanning terminal becomes available. Furthermore, suppose that the second scanning terminal can collect more information than the first scanning terminal.

[0080] In this case, the trust management device 100 causes the first scanning terminal to provisionally determine the degree to which the detected entity satisfies the expected specifications until the second timing, and then causes the second scanning terminal to re-determine the degree to which the detected entity satisfies the expected specifications after the second timing arrives.

[0081] Fig. 13 is a diagram showing the output of the trust management device in this embodiment. The trust management device 100 outputs the information shown in Fig. 13 via the user interface 106 or the remote terminal 13. For each target entity ("target" in Fig. 13) subject to trust management, the trust management device 100 outputs the entity category, expected specifications, trust level, criteria confirmation means, and the last confirmation date and time when the trust level was determined.

[0082] By checking the trust level or the last confirmed date and time, the user can identify entities that have problems in terms of trust management. In addition, other entities managed by the trust management device 100 may be involved as a means of checking the criteria.

[0083] The trust management device 100 in this embodiment can also obtain or track other entities that have confirmed the criteria of a certain entity. In other words, if entity 2 is used as a means to confirm the criteria of the expected specifications of entity 1, it can be said that the expected specifications of entity 1 have been verified by entity 2.

[0084] In other words, if it is later discovered that the expected specifications of entity 2 are not met, it will also be impossible to guarantee the validity of the expected specifications of entity 1. The trust management device 100 in this embodiment has a function to trace the means for checking the criteria as described above.

[0085] Furthermore, the contents of the security control process for the security control device 16 can be determined based on the trust level and the last confirmation date and time. In this case, the contents of the security control process will also be included in the output (table in FIG. 13). Note that, although the trust management process in this embodiment is exemplified by a device that exists as hardware, the implementation form is not limited to hardware and can be anything that executes a series of procedures. For example, procedures written in some programming language that assume cloud computing can also be applied.

[0086] The present invention is not limited to the above-described embodiments, but includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to those including all of the described configurations. Furthermore, it is possible to replace part of the configuration of one embodiment with the configuration of another embodiment, or to add the configuration of another embodiment to the configuration of one embodiment. Furthermore, it is possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

[0087] Furthermore, the above-mentioned configurations, functions, processing units, processing means, etc. may be partly or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-mentioned configurations, functions, etc. may also be implemented in software, with a processor interpreting and executing a program that implements each function. Information such as the programs, tables, and files that implement each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD. In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and do not necessarily show all the control lines and information lines in the product. In reality, it can be assumed that almost all components are interconnected. [Explanation of symbols]

[0088] 10 Industrial Control Systems (ICS) 11 ICS Network 12 System Components (Devices) 12-1 Software 13 Remote Terminal 14 Monitoring equipment 15 Scanning Terminal 16 Security control device 100 Trust Management Device 101 Storage section 104 CPU 105 Main memory 106 User Interface 107 Communication processing unit 301 System Design Information 302 System Operation Information 311 Input Information Analysis Unit 312 Expected Specification Generation Unit 313 Standard Specification DB 911 System Status Analysis Department 912 Information Collection Scheduler 913 Data Collection Instructions 1011 Collected Data Analysis Unit 1012 Trust Level Judgment Unit 1013 Notification and security control section

Claims

1. Generate an expected specification that the system expects from entities as system components from the design information or operation information of the system; collecting information about entities detected in the system for comparison with the expected specifications in a manner that minimizes impact on the system from the detected entities to a predetermined standard; storing measurable criteria for each of the plurality of expected specifications; evaluating the degree to which the detected entity satisfies the expected specification based on the criteria using qualitative or quantitative indicators; Obtaining or tracing the information on which the criteria are based; A trust management device comprising:

2. Generate an expected specification that the system expects from entities as system components from the design information or operation information of the system; collecting information about entities detected in the system for comparison with the expected specifications in a manner that minimizes impact on the system from the detected entities to a predetermined standard; A control system centralized management function including SCADA (Supervisory Control And Data Acquisition) or Historian is used, or an information collection schedule is formulated using the results of observing the status of the system based on log information generated by an information processing device that constitutes the system, Generate a scan instruction for selectively performing a passive scan or an active scan on a scanning terminal installed in the system according to the established information collection schedule; Switching between passive scanning and active scanning according to attribute information of the detected entity or an operating state of the system; If a second time comes when a second scanning terminal that can collect more information than the first scanning terminal becomes available after a first time when the first scanning terminal becomes available, the first scanning terminal is caused to provisionally determine a degree to which the detected entity satisfies the expected specification until the second time comes; causing the second scanning terminal to again determine the degree to which the detected entity meets the expected specifications after the second timing has arrived; A trust management device comprising:

3. Accepting design information or operation information of the system as a document input by a user in accordance with a predetermined format; 3. The trust management device according to claim 1 or 2, wherein:

4. generating the expected specifications by referring to a database in which the expected specifications are templated according to the classification of the components that make up the system; 3. The trust management device according to claim 1 or 2, wherein:

5. notifying a result of determining the degree to which the detected entity satisfies the expected specifications to a user interface of the trust management device or to an external device of the trust management device via a communication interface; generating a command to a security controller installed in the system based on the result of determining the degree to which the detected entity satisfies the expected specification; 3. The trust management device according to claim 1 or 2, wherein:

6. The trust management device A step of generating an expected specification that the system expects from entities as system components from design information or operation information of the system; collecting information about entities detected in the system for comparison with the expected specifications in a manner that minimizes impact on the system from the detected entities to a predetermined standard; evaluating the degree to which the detected entity satisfies the expectations based on measurable criteria stored for each of the expectations, using a qualitative or quantitative indicator; obtaining or tracking the information on which the criteria are based; A trust management method comprising:

7. The trust management device A step of generating an expected specification that the system expects from entities as system components from design information or operation information of the system; collecting information about entities detected in the system for comparison with the expected specifications in a manner that minimizes impact on the system from the detected entities to a predetermined standard; Formulating an information collection schedule using a control system centralized management function including SCADA (Supervisory Control And Data Acquisition) or Historian, or using results of observing the state of the system based on log information generated by information processing devices that constitute the system; generating a scan instruction for selectively performing passive scanning or active scanning on a scanning terminal installed in the system according to the established information collection schedule; Switching between passive scanning and active scanning according to attribute information of the detected entity or the operating state of the system; If a second time comes when a second scanning terminal that can collect more information than the first scanning terminal becomes available after a first time when the first scanning terminal becomes available, causing the first scanning terminal to provisionally determine the degree to which the detected entity satisfies the expected specifications until the second time comes; after the second timing has arrived, causing the second scanning terminal to again determine the degree to which the detected entity meets the expected specifications; A trust management method comprising:

Images