JP7808912B2 - Trust management device and trust management method - Google Patents

Description

The present invention relates to a trust management device and a trust management method.

In recent years, 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 IoT (Internet of Things) devices are introduced into ICS, the sources of attacks are diversifying, with malicious software entering the ICS via IoT devices and malicious software being installed on various devices within the ICS via the supply chain. Meanwhile, in order to promote DX (Digital Transformation) of ICS, 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.

In addition, security measures based on the idea of zero trust are beginning to spread, particularly in enterprise (large company) information systems. These measures are based on the idea of "designing security defenses based on the assumption that malicious software has infiltrated the system network," rather than traditional perimeter defense, and involve strengthening security at endpoints and implementing strict access control policy management.

However, unlike enterprise information systems, ICSs have poor embedded computer processing performance and are replaced or updated less frequently than enterprise systems. For these reasons, there are still challenges in applying zero trust architecture to ICSs as is. As a result, it is difficult to implement security verification and control measures at all endpoints, and a trust management architecture suitable for ICSs must be realized while taking these challenges into account.

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

The technology in 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 that access.

Special Publication No. 2009-518762

ISO/IEC TR 24028:2020(E), p6, 3.42

According to Patent Document 1, access permission can be determined based on multiple pieces of integrity information received from the 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 open technology becomes more complex, 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.

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 ICS, such as system design specifications and operating conditions, and Patent Document 1 does not take this into consideration sufficiently.

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 in ICS where it is not possible to install an information collection agent on the client, or where it is not possible to perform information collection (active scanning) by verifying responses after sending various communication data to the target device.

The object of this invention is to provide a mechanism for collecting and evaluating information to determine trust in ICS, taking into account issues that could not be resolved with these prior art technologies, in a way that minimizes the impact on ICS operation.

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 about entities detected in the system in a way that minimizes the impact on the system to a level that meets specified standards , storing measurable criteria for each of a plurality of expected specifications, evaluating the degree to which the detected entities fulfill the expected specifications based on the criteria using qualitative or quantitative indicators, and obtaining or tracking the information that served as the basis for the criteria .

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 must meet. Here, the specifications that the system must meet are the design specifications of the target system and the conditions for system operation.

In other words, the system (ICS) as a whole expects certain specifications from the individual entities that make up its structure. Entities here 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 entity actually possesses (information about the entity). Of course, the information that an entity actually possesses can be compared with the expected specifications.

Here, system design specifications refer to system design information including system requirements specifications, which include non-functional requirements, and system configuration specifications, such as system network information and device configuration.

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 communicate encrypted, or when the system verifies this. This system requirement can be taken from the system design document or defined individually by the system administrator.

In addition, system operational information consists of information about system operation, such as the environment in which the system is located and operation manuals for system users. For example, if a system handles safety control functions for important control processes using applications, the importance of the applications handled by the system (the severity of a problem when it occurs) would be an example of the environment in which the system is located.

The present invention is a trust management device and trust management method that generate specifications (expected specifications) that a system expects from entities from the system design information and system operation information described above.

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 above-mentioned trust while minimizing the impact on the system (ICS). The method used in this invention is characterized by observing and evaluating the system's operating status and device characteristics, and scheduling information collection procedures based on the observation and evaluation results and expected specifications.

The present invention makes it possible to provide a mechanism for collecting and evaluating information to determine trust in an ICS in a way that minimizes the impact on ICS operations.

1 is a diagram illustrating the overall configuration of the present embodiment. FIG. 2 is a diagram illustrating an example of a hardware configuration of a trust management device according to the present embodiment. FIG. 10 is a diagram illustrating the operation of an expected specification generation process in this embodiment. FIG. 2 is a diagram showing an input screen for system design information in the present embodiment. FIG. 10 is a diagram showing an input screen for system operation information in the present embodiment. FIG. 10 is a diagram showing an input analysis processing flow in the present embodiment. FIG. 10 is a diagram showing an expected specification generation processing flow in the present embodiment. FIG. 10 is a diagram showing a list of expected specifications in the present embodiment. FIG. 10 is a diagram showing a trust level determination criteria table in the present embodiment. 10A and 10B are diagrams illustrating an information scan control operation in the present embodiment. FIG. 10 is a diagram illustrating a trust level determination operation in this embodiment. FIG. 10 is a diagram showing a processing flow when a new entity is detected in this embodiment. FIG. 10 is a diagram illustrating scan switching timing in the present embodiment. FIG. 10 is a diagram showing an output of the trust management device in this embodiment.

<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.

Figure 1 is an overall configuration diagram 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 comprises many components (entities) 12-16. The trust management device 100 determines whether these components meet expected specifications based on the zero trust concept.

A trust management device 100 is connected to the ICS network 11. System components 12, such as control devices, are connected to the ICS network 11 and perform business-related processing. Software 12-1 that controls the hardware of the system component 12 is installed in the system component 12, and performs specified information processing functions.

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

Connected to the ICS network 11 is a monitoring device 14 that observes and collects information about 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. Examples of the monitoring device 14 include ICS components (centralized control system management functions) called SCADA (Supervisory Control And Data Acquisition) and Historian.

The ICS network 11 is also connected to a scan terminal 15, which collects information related to trust decisions from entities that have newly joined the ICS network 11 and from devices that are already connected. The trust management device 100 has the authority to control the scan terminal 15's information collection and execution of scan processing.

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

<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 calculations, a main memory 105 consisting of volatile memory elements into which programs and data are loaded and which stores data for executing calculations, a user interface 106 that handles data exchange between the computer and the user, and a communication processing unit 107 that handles communication processing between other computers.

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 may be, for example, a non-volatile storage element such as a hard disk drive (HDD) or a solid state drive (SDD).

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

The user interface 106 is configured as a command line interface (CLI) or a graphical user interface (GUI) that is input on a command basis, 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.

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

<Mechanism for generating expected specifications in the present 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.

Program 102 includes an input information analysis unit 311 and an expected specification generation unit 312. First, the input information analysis unit 311 extracts the information necessary to generate 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 to generate the expected specifications.

The input information analysis unit 311 may generate expected specifications by reading templated input and extracting tagged information, or it may extract information necessary to generate expected specifications by performing text mining on the system design information 301.

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

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

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

System information is entered separately as network information and asset information for the trust management system. Examples of network information include network topology, the type of network (wired LAN, wireless LAN, serial network, etc.), and the connection relationships between nodes participating in the network.

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, the asset name, as well as the entity type and subcategory, and the entity requirement specification definition information for realizing the system.

Figure 4B is a diagram showing the system operation information input screen 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 individual information related to system operation. Examples of document files include documents (documents that follow a specified format) created using document creation software used in OA (Office Automation) tasks. As with the system design information input shown in Figure 4A, multiple related files can also be input.

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.

Figure 5 shows the input analysis processing flow in this embodiment. This input analysis processing is executed by program 102 (input information analysis unit 311) in the trust management device 100.

In step S501, the input information analysis unit 311 receives the system design information 301 or 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 from the input information the information required to construct a system structure model and an operation model required to generate expected specifications.

In step S502, the input information analysis unit 311 generates a system structure model that represents the expected specifications based on the input system design information 301. This system structure model is defined as metadata consisting of multiple attribute information.

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 defined as metadata consisting of multiple attribute information.

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 remote terminal 13.

Figure 6 shows the expected specification generation processing flow in this embodiment. This expected specification generation processing is also executed by 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 Figure 5.

In step S601, the expected specification generation unit 312 analyzes the structured data and extracts the information necessary to generate the expected specification model.

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 in 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.

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

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

Figure 7 shows the 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 Figure 3, and associates point domains, trust targets, expected specifications, and criteria with each other.

A point domain is a network, component, etc. on a trusted management system.
The trust target is, for example, a list of components connected to the "control information network."

The expected specifications are defined in the form of system requirements specifications 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 a public key encryption processing function of TLS (Transport Layer Security) v1.3 or higher" or "confirming that the system has a symmetric key encryption function equivalent to AES (Advanced encryption standard)."

Note that expected specifications can also be organized from various perspectives related to trust. For example, expected specifications for an entity can be determined according to characteristics such as authenticity, reliability, protectivity, security, quality, and resilience. Note that characteristics related to expected specifications are not limited to the items mentioned above.

Figure 8 shows the 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 Figure 7. The trust level determination criteria table is also part of the expected specification template stored in the standard specification DB 313 in Figure 3.

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

The trust level is a numerical value that indicates the results of verification using the detailed verification method. For example, trust level "1" is defined for "manual input by a trusted user." Trust level "2" is defined for "confirmation from a software library that a TLS communication library is included." Trust level "3" is defined for "confirmation of TLSv1.3 session establishment using communication capture or active scanning." Trust level may be a qualitative specification such as level 1 or level 2, or 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.

Figure 9 is a diagram showing the information scanning 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 operating status information acquired from SCADA, Historian, and log information of each information processing device that makes up the system, network processing load status information, information on the processing load status of the information processing device, etc.

Using the system state composed of this information as input information, the system state analysis unit 911, which is loaded from program 102 in the trust management device 100 into main memory 105, executes a system state analysis process. 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 over time.

The information collection scheduler 912 formulates an information collection schedule for evaluating the degree of satisfaction with expected specifications based on the analysis results and model information of the trust management target system. The data collection instruction 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 instruction unit 913 transmits the data collection instruction to each scan terminal 15 via the communication processing unit 107.

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

The collected data analysis unit 1011 analyzes the input entity-related data in a manner that satisfies the detailed verification method defined 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 of FIG.

The notification/security control unit 1013 then displays the trust level determination result or determines the security control content.

The notification/security control unit 1013 notifies the trust level determination result to the local user interface within 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/security control unit 1013 sends a security control instruction to each security control device 16 connected to the ICS network 11 via the communication processing unit 107.

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.

In step S1102, each scanning terminal 15 performs 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 also detect the existence of a new entity from the log information output by the monitoring device 14.

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.

Next, we will describe a method for scanning information in this embodiment that minimizes the impact on the ICS.

Figure 12 is a diagram showing the timing of scan switching in this embodiment. For example, suppose that the graph shown in Figure 12 is obtained as a result of the monitoring device 14 monitoring the time change in network load as a system state. As is generally known, there are two types of scanning methods: passive scanning, which does not generate communication data itself, and active scanning, which generates communication data itself and can observe the response. The scanning terminal 15 switches between these two methods.

Specifically, for example, at peak times (maximum network load points), the scanning terminal 15 refrains from active scanning, which generates excessive communication, and only performs passive scanning, which does not generate excessive communication. When the bandwidth has settled down (minimum network load points), the scanning terminal 15 performs active scanning.

This makes it possible to collect the maximum amount of information when the system (ICS) is under low load. ICSs often perform certain processes periodically, so 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 performs active scanning when the network load is decreasing.

In addition, there is also a method for determining the scanning method depending on the attributes of the scan target. For example, the scanning terminal 15 performs active scanning regardless of the timing for host devices with sufficiently large computing resources, such as industrial personal computers and server equipment. When the scanning terminal 15 is in an operation mode such as "maintenance" or "trial run," there is no impact on business operations that could lead to a system shutdown, so it always performs active scanning.

In Figure 12, the scanning terminal 15 performs an active scan at a minimum point in the network load, but this is just one example. The monitoring device 14 may also 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 specified standards. 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 by machine learning past time-series changes in network load.

In other words, to minimize the impact on the system, the trust management device 1 generates scan instructions to selectively perform passive or active scans on the scan terminals 15 installed within the system (ICS) in accordance with the established information collection schedule.

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 status 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 the second scanning terminal is capable of collecting more information than the first scanning terminal.

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. Then, after the second timing arrives, the trust management device 100 causes the second scanning terminal to again determine the degree to which the detected entity satisfies the expected specifications.

Figure 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 Figure 13 via the user interface 106 or the remote terminal 13. For each target entity ("Target" in Figure 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.

By checking the trust level or last confirmed date and time, users can identify entities with trust management issues. In addition, other entities managed by the trust management device 100 may be involved in verifying the criteria.

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 of confirming 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.

In other words, if it is later discovered that the expected specifications of Entity 2 are not met, the validity of the expected specifications of Entity 1 cannot be guaranteed. The trust management device 100 in this embodiment has the ability to trace the means for verifying the above-mentioned criteria.

The content of the security control process for the security control device 16 can also be determined based on the trust level and the last confirmation date and time. In this case, the content of the security control process will also be included in the output (table in Figure 13). Note that, although the trust management process in this embodiment is illustrated as an example of 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.

The present invention is not limited to the above-described embodiments, and includes various modifications. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are 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.

Furthermore, the above-described configurations, functions, processing units, processing means, etc. may be partially or entirely implemented in hardware, for example, by designing them as integrated circuits. The above-described 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.

10. Industrial Control Systems (ICS)
11 ICS network 12 System components (devices)
12-1 Software 13 Remote terminal 14 Monitoring device 15 Scan terminal 16 Security control device 100 Trust management device 101 Storage unit 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 state analysis unit 912 Information collection scheduler 913 Data collection instruction unit 1011 Collection data analysis unit 1012 Trust level determination unit 1013 Notification and security control unit

Claims (7)

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: 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: 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: 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: 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: 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: 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: