Control device, computer-readable storage medium, and software component table management system

Abstract

A control device according to the present disclosure comprises: an investigation request reception unit for receiving an investigation request for vulnerability of software installed in the control device; a vulnerability investigation unit for acquiring a software component table of the software and vulnerability information, and investigating the vulnerability of the software included in the control device; and a device control unit for limiting the operation of the software requiring a countermeasure.

Description

Control device, computer-readable storage medium, and software parts bill management system

[0001] The present disclosure relates to a control device, a computer-readable storage medium, and a software bill of materials management system.

[0002] In recent years, IT-based factories known as smart factories have emerged. In smart factories, core systems, manufacturing execution systems, and production equipment are connected via a network. In smart factories, manufacturing history data is linked to and stored with product information, making it possible to visualize quality and aggregate various data such as production volume, parts procurement, defective product occurrence rate, factory operating hours, and consumable replacement information, thereby making it possible to visualize the status of the manufacturing site.

[0003] Such information-based factory networks are hierarchical, consisting of a control system network that controls industrial machinery and a higher-level information system network.

[0004] Factory networks are different from general information technology (IT) and are called operational technology (OT). Security measures in factories place emphasis on availability and integrity.

[0005] Conventionally, there has been a monitoring system for managing the security of a factory network that records information about files held by terminals connected to an information network, verifies the vulnerabilities of the files, and determines how to deal with the vulnerabilities based on a policy. For example, see Patent Document 1.

[0006] Japanese Patent Application Laid-Open No. 2006-40196

[0007] To address vulnerabilities, industrial machinery users must obtain the software bill of materials (SBOM) of the industrial machinery, determine what vulnerabilities the machinery contains, and then restrict the machinery's operation. Determining vulnerabilities and restricting operation by users takes time and effort, and requires personnel with security expertise. When industrial machinery is subject to a cyber attack, an emergency response is required to prevent the damage from spreading, but there are circumstances in which it is not possible to allocate sufficient resources to security measures.

[0008] At manufacturing sites, there is a desire to reduce the burden on users associated with security measures for control devices.

[0009] A control device according to one aspect of the present disclosure includes software, an investigation request receiving unit that receives an investigation request for vulnerabilities in the software, a vulnerability investigation unit that acquires a software parts list and vulnerability information for the software and investigates vulnerabilities in the multiple pieces of software, and a device control unit that restricts the operation of software that has vulnerabilities that require countermeasures.

[0010] 1 is a diagram showing the network configuration of a factory. FIG. 2 is a block diagram of a control device. FIG. 3 is a diagram showing acquisition paths for vulnerability information and SBOM. FIG. 4 is a diagram showing an example of vulnerability information. FIG. 5 is a diagram showing an example of SBOM. FIG. 6 is a diagram showing an example of a countermeasure list. FIG. 7 is a diagram showing the operation of a numerical control device according to a countermeasure procedure. FIG. 8 is a diagram showing an example of a countermeasure list. FIG. 9 is a diagram showing the operation of an equipment control unit according to a countermeasure procedure. FIG. 10 is a diagram showing an example of a countermeasure history. FIG. 11 is a diagram showing an example of a parts list including software identification information. FIG. 12 is a diagram showing an example of a vulnerability list. FIG. 13 is a diagram showing the operation of an equipment control unit. FIG. 14 is a diagram showing an example of a vulnerability countermeasure record. FIG. 15 is a diagram showing the configuration of an SBOM management system. FIG. 16 is a diagram showing management information of SBOM in an SBOM management device. FIG. 17 is a diagram showing the procedure for adding an SBOM. FIG. 18 is a diagram showing the procedure for fully updating an SBOM. FIG. 19 is a diagram showing the procedure for partially deleting an SBOM. FIG. 20 is a hardware configuration diagram of a control device.

[0011] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the following description, components having the same or similar functions will be denoted by the same reference numerals. Duplicate descriptions of those components may be omitted.

[0012] In this application, "based on XX" means "based on at least XX," and includes cases where it is based on other elements in addition to XX. Furthermore, "based on XX" is not limited to cases where XX is used directly, but also includes cases where it is based on XX that has been calculated or processed. "XX" is any element (for example, any information).

[0013] First, the positioning of the control device 100 will be explained with reference to FIG. 1. A factory network is mainly composed of a field network made up of devices such as sensors and motors, a controller network made up of control devices that control the devices, and an information network that is an IT environment. The control device 100 is included in the controller network. The controller network is positioned between information technology (IT) and devices. Examples of control devices include a programmable logic controller (PLC) and a numerical control device.

[0014] 2 is a block diagram of a control device 100 according to a first embodiment. The control device 100 includes an SBOM (Software Bill of Materials) storage unit 1, an investigation request receiving unit 2, a vulnerability investigation unit 3, and a device control unit 4. The control device 100 has multiple pieces of software installed. For example, in a numerical control device or a PLC, information system software and control system software related to the control of industrial machinery are installed.

[0015] The manufacturer of the control device 100 provides an SBOM to reduce security risks of the control device 100. The SBOM is a list of software installed on the control device and the components that make up the software. The contents of the SBOM change over time. For example, the SBOM is rewritten with the latest information whenever the contents of the software installed on the control device change, such as when a software developer updates the software, a system integrator adds software to the control device 100, or a software pre-installed on the control device is updated. The SBOM holds the latest information about the software installed on the control device.

[0016] The investigation request receiving unit 2 receives a request for an investigation of vulnerabilities in software installed in the numerical control device. The timing of the request for the vulnerability investigation may be periodically, such as every day or every three hours, may be triggered by a user instruction, or may be an emergency investigation request when a threat such as a cyber attack is detected.

[0017] When the vulnerability investigation unit 3 receives a vulnerability investigation request, it acquires vulnerability information and the SBOM and investigates vulnerabilities in the software included in the control device 100. As shown in FIG. 3 , the vulnerability information can be acquired from an external vulnerability information database. The SBOM is managed by the manufacturer of the control device 100 (including software developers, system integrators, etc.). The vulnerability information database and the SBOM are updated as needed. The vulnerability investigation unit 3 acquires the vulnerability information and the SBOM as needed and investigates vulnerabilities in the control device 100.

[0018] Vulnerability information can be obtained from an external vulnerability information database. Examples of vulnerability information databases include the National Vulnerability Database (NVD) managed by the National Institute of Standards and Technology (NIST) and Japan Vulnerability Notes (JVN) managed by the Information-Technology Promotion Agency (IPA). There are no particular limitations on the type of vulnerability information database.

[0019] The vulnerability investigation unit 3 searches for vulnerabilities in software installed in the control device 100. The vulnerability information includes software (or component) identification information and the impact of the vulnerability. FIG. 4 shows an example of vulnerability information for an NVD. The vulnerability information for an NVD includes a CVE (Common Vulnerabilities and Exposures) number, details, impact, and a CPE-ID. A CVE number is a unique number assigned to each vulnerability. Each vulnerability can be uniquely identified by the CVE number. In the example of FIG. 4, the vulnerability details are also included. The details include a description of the vulnerability, such as "Package A has an out-of-bounds write vulnerability." The impact is a numerical value that quantifies the impact of the vulnerability. In the example of FIG. 4, the CVSS value (Common Vulnerability Scoring System) is used as a vulnerability quantification method. The CVSS value is an example of a vulnerability evaluation method. The impact calculation method is not limited to the CVSS value. The cpe-id (common platform enumeration-id) is identification information for each piece of hardware and software that makes up an information technology system. The CPE is a naming convention adopted by NVD. The CPE has a structure such as "cpe: / {part}:{vendor}{product}:{version}:{update}:{edition}:{language}". The {part} item indicates the type of product in which the vulnerability occurred, such as hardware, operating system, application, driver, library, etc. The {vendor} item describes the vendor name. The {product} item describes the product name. The {version} item describes the product version information. The {update} item describes information about product updates and service packs. The {edition} item describes the product edition. The {language} item is used to specify the language used in the product. The cpe-id can be used to identify software containing vulnerabilities.In the example of FIG. 4, it can be seen that the vulnerability "CVE-2022-3775" has an impact level of "8.1", a package name of "Package A", and a version range of "0.0<version<2.0.6".

[0020] The SBOM (Software Bill of Materials) is created by the manufacturer of the control device 100 and provided to the user of the control device 100. By referencing the SBOM, the components that make up the software included in the control device 100, the component dependencies, license data, and the like can be determined. FIG. 5 shows an example of an SBOM (Software Bill of Materials). The SBOM includes the name of the control device 100, the name of the software included in the control device 100, the software version number, the software package name, the package version number, and the like. The SBOM includes information not only about commercial software but also about open source components. Note that SBOMs are created by individual companies, and the format is not completely standardized. The SBOM may also include software dependencies, the SBOM creator, a timestamp, and the like.

[0021] As described above, the vulnerability investigation unit 3 obtains the software package name and version number from the SBOM. The vulnerability investigation unit 3 also obtains software vulnerabilities in the control device 100 from the vulnerability database. Each vulnerability is assigned a CVE number as identification information. The vulnerability investigation unit 3 obtains the impact of the vulnerability using the CVE number as a key.

[0022] If the impact of a vulnerability is equal to or greater than a predetermined threshold, the vulnerability investigation unit 3 considers the vulnerability to require an emergency response. For example, if the impact of a software vulnerability obtained from the vulnerability database exceeds the threshold "8.0," the vulnerability investigation unit 3 outputs an emergency response request to the device control unit 4. The emergency response request includes the CVE number, impact, etc. If multiple vulnerabilities exist, the vulnerability investigation unit 3 may find the maximum impact of the vulnerabilities. If the maximum impact is equal to or greater than a predetermined threshold, the vulnerability investigation unit 3 considers the vulnerability to require an emergency response.

[0023] The device control unit 4 restricts the use of software depending on the impact of the vulnerability. Three methods for dealing with vulnerabilities in the device control unit 4 will be described.

[0024] <Software Operation Restrictions> In the first method, the operation of software that affects the assets to be protected is restricted according to the impact of the vulnerability. The device control unit 4 maintains a countermeasure list. The countermeasure list specifies the impact of the vulnerability and the countermeasure procedure. The countermeasure procedure specifies the software operation restrictions.

[0025] Depending on the impact of the vulnerability, the countermeasure procedures may, for example, restrict changes to parameters and other data related to factory operations, or restrict external access that is usually carried out for maintenance, etc. They may also restrict access from the segment where the vulnerable software exists or disable ports.

[0026] The countermeasure procedures specify countermeasures that the control device can implement to prevent the spread of malware intrusions and suspicious access, taking into consideration the factory's network configuration, resource allocation, etc.

[0027] An example of a countermeasure list is shown in Figure 6. The countermeasure list in Figure 6 specifies the vulnerability impact level "8.0-9.0" and countermeasure procedure A "stop correction register update software A, output alarm A," impact level "9.0-9.5" and countermeasure procedure B "stop register and parameter input / output software B, prohibit program execution, output alarm B," impact level "9.5-9.9" and countermeasure procedure C "stop data input / output software C, stop program execution, output alarm C," and impact level "9.9-10.0" and countermeasure procedure D "forced program termination due to alarm, forced termination of data input / output software C, output alarm D, power off after processing is completed."

[0028] The device control unit 4 refers to the countermeasure procedure and instructs the execution control unit 5 to restrict the operation of the software. The execution control unit 5 executes the specified software stop, immediate stop, forced stop, etc. Figure 7 shows the operation of the device control unit 4 according to the countermeasure procedure. When the impact level of the vulnerability is "8.1", the device control unit 4 executes countermeasure procedure A. (1) The device control unit 4 instructs the execution control unit 5 to stop correction register update software A. (2) The execution control unit 5 stops software A in accordance with the instruction from the device control unit 4. (3) When software A stops, the execution control unit 5 turns off the execution flag for software A. The execution control unit 5 checks the flag and, if software A is stopped, (4) notifies the device control unit 4 that the stop is complete.

[0029] <Restricting the operation of communications software> The second method involves restricting the use of communications software according to the impact of the vulnerability. Communications software is software that controls communications with other devices and keeps records of communications according to a specific protocol. As shown in Figure 1, factory networks include information networks, controller networks, and field networks. Controller networks and field networks have factory-specific protocols. Each protocol has different connected devices, environments, and uses. For example, there are protocols that are suitable for communication between controllers and protocols that are suitable for motion control.

[0030] The device control unit 4 maintains a countermeasure list. The countermeasure list specifies the impact of vulnerabilities and countermeasure procedures. The countermeasure procedures specify operational restrictions on the communication software.

[0031] An example of a countermeasure list is shown in Figure 8. The countermeasure list in Figure 8 specifies the vulnerability impact level "8.0-9.0" and countermeasure procedure A "Stop Ethernet communication software A and output alarm A," impact level "9.0-9.5" and countermeasure procedure B "Immediately stop communication software A, B, and C, stop program startup, and output alarm B," impact level "9.5-9.9" and countermeasure procedure C "Forcefully stop communication software on all ports and output alarm C," and impact level "9.9-10.0" and countermeasure procedure D "Forcefully terminate programs due to alarm, forcefully stop communication software on all ports, output alarm D after the forced stop, and turn off the power after processing is complete."

[0032] The device control unit 4 instructs the execution control unit 5 to restrict the operation of the communications software according to the countermeasure procedure. The execution control unit 5 executes the specified software stop, immediate stop, forced stop, etc. Figure 9 shows the operation of the device control unit 4 according to the countermeasure procedure. When the impact level of the vulnerability is "8.1", the device control unit 4 executes countermeasure procedure A. (1) The device control unit 4 instructs the execution control unit 5 to stop communications software A. (2) The execution control unit 5 stops communications software A in accordance with the instruction from the device control unit 4. (3) When communications software A stops, the execution control unit 5 turns off the execution flag for communications software A. The execution control unit 5 checks the flag and, if communications software A has stopped, (4) notifies the device control unit 4 that the stop has been completed.

[0033] When the communication software A has been stopped, (5) the device control unit 4 instructs the alarm control unit 6 to output alarm A. The alarm control unit 6 controls the output of alarm comments and alarm sounds. (6) The alarm control unit 6 outputs alarm A in accordance with the command from the device control unit 4. There are no particular limitations on the type of alarm. The alarm may be a sound or a screen display.

[0034] The device control unit 4 records the execution results of the countermeasure procedures as a countermeasure history. In Fig. 10, the countermeasure history records the CVE number "CVE2022-3775", the impact level "8.1", the execution procedure "A", the date "2014 / 2 / 13", and the time "13:35:40.23".

[0035] <Individual Operation Restrictions on Vulnerable Software> Next, a method for individually restricting the operation of vulnerable software will be described. In this method, as shown in FIG. 11 , software identification information (called a soft ID) is added to the SBOM. The soft ID is assigned to each piece of software by an SBOM administrator, such as the manufacturer of the control device 100 (and the software developer). The vulnerability investigation unit 3 sends an API (Application Programming Interface) or the like to the vulnerability database and searches for vulnerable software among the software included in the SBOM. Specifically, the package name and version number of the software managed by the SBOM are searched for by referencing the "cpe-id" in the vulnerability database.

[0036] If vulnerable software is found, the vulnerability investigation unit 3 determines whether or not emergency measures are required for the vulnerability. To determine whether emergency measures are required, for example, the impact of the vulnerability is compared with a threshold. If the impact exceeds the threshold, the vulnerability investigation unit 3 determines that emergency measures are required. The vulnerability investigation unit 3 creates a list of software requiring emergency measures (called a vulnerability list) and outputs it to the device control unit 4. Figure 12 is an example of the vulnerability list. The vulnerability list includes a CVE number, which is an identification number unique to the vulnerability, a software ID that identifies the software of the control device, and the impact of the vulnerability.

[0037] The device control unit 4 restricts the operation of software that requires emergency measures. Figure 13 shows the operation of the device control unit 4. The device control unit 4 (1) sorts the vulnerability list in order of impact, and (2) instructs the execution control unit to restrict the operation of software with high impact. The instruction includes a software ID that identifies the software. (3) The execution control unit 5 identifies the vulnerable software (referred to as software A) based on the software ID, and (4) instructs the software execution unit (referred to as software execution unit A) to perform an emergency stop. (5) When software execution unit A receives the emergency stop command, it stops the execution of software A. (6) Software execution unit A turns on the execution completion flag of software A. The execution completion flag being on means that the execution of the software has completed.

[0038] (7) After outputting an emergency stop command for software A, the device control unit 4 instructs the execution control unit 5 to restrict the operation of the software in the second row of the vulnerability list (referred to as software B) after a predetermined interval (1 minute). The instruction includes a software ID that identifies the software. (8) The execution control unit 5 identifies the vulnerable software (referred to as software B) based on the software ID, and (9) instructs the software execution unit (referred to as software execution unit B) to perform an emergency stop. (10) The software execution unit B stops software B. (11) The software execution unit B turns off the software execution completion flag. The execution completion flag being off means that the software has been interrupted.

[0039] The execution control unit 5 stops all software in the vulnerability list and waits for a predetermined interval (e.g., 10 minutes). The device control unit 4 creates a vulnerability countermeasure record. Figure 14 shows an example of a vulnerability countermeasure record. The vulnerability countermeasure record includes the CVE number in the vulnerability list, the software ID, the impact, the date, the time, and the status of the execution completion flag.

[0040] Individual operation restrictions on vulnerable software restrict operation according to the impact of the software vulnerability. The control device 100 registers the details of the operation restrictions and the operating status of each piece of software in the vulnerability countermeasure record. The vulnerability countermeasure record can be used to confirm whether the software has stopped completely (normally). The vulnerability countermeasure record can be used for maintenance and restarting industrial machinery.

[0041] The impact level in this embodiment may be created by factory engineers, security experts, etc. Specifically, the impact level on assets to be protected when software has a vulnerability is evaluated from the perspectives of availability, integrity, and confidentiality.

[0042] Second Embodiment In the second embodiment, an SBOM management system 300 including an SBOM management device 200 and a control device 100 will be described. As shown in FIG. 15 , the SBOM management system 300 includes an SBOM management device 200 and a plurality of control devices connected via a local network. The SBOM management device 200 has the function of managing a plurality of SBOMs. FIG. 16 shows SBOM management information in the SBOM management device 200. Identification information (control device ID) is assigned to each control device in a factory. The SBOM management device 200 stores the control device ID and the SBOM in association with each other.

[0043] Control device 100 stores its own SBOM in SBOM storage unit 1. When software is added, changed, or deleted, SBOM is updated according to SBOM management device 200. Addition, full update, and partial deletion of SBOM will be described below.

[0044] <Adding SBOM> Figure 17 is a diagram showing the procedure for adding an SBOM. Software is often added by the manufacturer of the control device 100 or a system integrator. When software is added to the control device 100, information about the added software is added to the SBOM. Addition to the SBOM can be automatic or manual. When the SBOM of a control device 100 is added, the SBOM management device 200 outputs a change request to the control device 100. As shown in Figure 17, the change request can specify changes such as "add," "partial delete," "full update," and "full delete." In this example, the "add" flag is ON.

[0045] SBOM management device 200 transmits an SBOM change request and information to be added to the SBOM to control device 100. Control device 100 adds the acquired information to the SBOM in response to the change request.

[0046] <SBOM Total Update> Figure 18 is a diagram showing the procedure for a total update of the SBOM. When an updater (such as a manufacturer or system integrator of the control device 100) performs a total update of the software of the control device 100, the updater also performs a total update of the SBOM information. When the SBOM of a certain control device 100 is completely updated, the SBOM management device 200 outputs a change request to that control device 100. In a total SBOM update, as shown in Figure 18, the "total update" flag in the change request is set to ON.

[0047] When the SBOM of control device 100 is fully updated, SBOM management device 200 transmits an SBOM change request and new SBOM information to control device 100. In response to the change request, control device 100 deletes the current SBOM and registers the new SBOM information.

[0048] <Partial Deletion of SBOM> Figure 19 is a schematic diagram showing the procedure for partially deleting an SBOM. When an updater (such as a control device manufacturer or system integrator) partially deletes software from a control device 100, the updater also partially deletes information from the SBOM. When the SBOM of a certain control device 100 is partially deleted, SBOM management device 200 outputs a change request to that control device 100. In the partial deletion of an SBOM, the "partial deletion" flag in the change request is ON, as shown in Figure 19.

[0049] Control device 100 acquires an SBOM change request and information on the part to be deleted from SBOM management device 200. SBOM storage unit 1 deletes part of the SBOM in response to the change request.

[0050] As described above, when the control device 100 of this embodiment receives an external vulnerability investigation request, it acquires vulnerability information for software implemented in the control device 100 and restricts the operation of the software. In the current OT environment, it is difficult to build a monitoring system like an IT system. In this embodiment, each control device 100 determines vulnerabilities and immediately implements necessary operational restrictions. The control device 100 can independently implement operational restrictions without delay. Furthermore, by being able to do this independently, it is possible to take into account the operating status of industrial machinery. For example, it becomes possible to perform operations such as vulnerability assessment before machining and confirming safety before starting machining.

[0051] According to this embodiment, the control device 100 acquires vulnerability information and implements countermeasures against the vulnerabilities, so that even if there is no personnel knowledgeable about security, security countermeasures can be implemented by the control device 100. Because the control device 100 implements countermeasures, even if a factory or company is subjected to a cyberattack, emergency security countermeasures can be implemented within the control device 100, and damage from the cyberattack that would occur due to a delay in implementing the countermeasures can be avoided.

[0052] There are two methods for restricting software operation: restricting the operation of communication software depending on the impact of the vulnerability, and restricting the operation of individual software that has vulnerabilities. Restricting the operation of communication software allows production to continue by disconnecting the upper network depending on the impact of the vulnerability. Restricting individual operation involves disconnecting vulnerable software to protect the security of software that does not have vulnerabilities. In addition, when the operation of vulnerable software is restricted, a vulnerability countermeasure record is created. The vulnerability countermeasure record allows users to check the state of the software when it was stopped (whether the software was stopped completely (normally)).

[0053] In the second embodiment, an SBOM management device 200 is installed in a local facility such as a factory. The SBOM management device 200 manages the SBOMs of multiple control devices 100 in the factory. Each SBOM is linked to the identification information (control device ID) of the control device 100. When a manufacturer or system integrator of the control device 100 updates the software of the control device 100, the SBOM management device 200 outputs an update request and update details to the control device 100 whose software has been updated. The control device 100 updates the SBOM in accordance with the update details. According to the second embodiment, when a manufacturer or system integrator of the control device 100 updates the SBOM of the SBOM management device 200 at the same time as updating the software, the SBOM of the control device 100 is updated. The user of the control device 100 does not need to spend time managing the SBOM and can avoid missing updates.

[0054] The hardware configuration of the control device 100 to which the present disclosure is applied will be described below. Fig. 20 is a hardware configuration diagram of the control device 100. Note that the SBOM management device also has a similar hardware configuration. A description of the hardware configuration of the SBOM management device 200 will be omitted. As shown in Fig. 20, the control device 100 includes a CPU 111 that controls the entire control device 100, a ROM 112 that records programs and data, and a RAM 113 for temporarily expanding data, and the CPU 111 reads out a system program recorded in the ROM 112 via a bus.

[0055] The nonvolatile memory 114 is backed up by, for example, a battery (not shown), and the stored state is maintained even when the power supply to the control device 100 is turned off. The nonvolatile memory 114 stores various data such as programs read from the external device 120 via the interfaces 115, 118, and 119 and operation inputs input via the input device 20. The nonvolatile memory 114 may store programs and data for executing the control device 100 of this embodiment.

[0056] The interface 115 is an interface for connecting the control device 100 to an external device 120 such as an adapter. Programs, various parameters, etc. are loaded from the external device 120. The interface 118 is an interface for connecting the control device 100 to a display device 30 such as a liquid crystal display. The display device 30 displays various data loaded into memory, data obtained as a result of executing programs, etc. The interface 119 is an interface for connecting the control device 100 to an input device 20 such as a keyboard or pointing device. The input device 20 passes commands, data, etc. based on operations by an operator to the CPU 111 via the interface 119.

[0057] Although the present disclosure has been described in detail, the present disclosure is not limited to the individual embodiments described above. Various additions, substitutions, modifications, partial deletions, etc. are possible in these embodiments without departing from the gist of the present disclosure or the gist of the present disclosure derived from the claims and their equivalents. Furthermore, these embodiments can also be implemented in combination. For example, in the above-described embodiments, the order of each operation and the order of each process are shown as examples and are not limited to these.

[0058] The following are supplementary notes related to embodiments of the present disclosure. (Supplementary Note 1) A control device (100) includes an investigation request receiving unit (2) that receives an investigation request for vulnerabilities in software installed in the control device (100), a vulnerability investigation unit (3) that acquires a software parts list and vulnerability information for the software and investigates vulnerabilities in the software, and a device control unit (4) that restricts the operation of software that requires countermeasures. (Supplementary Note 2) The vulnerability investigation unit (3) acquires information about software installed in the control device (100) from the software parts list and acquires vulnerability information for each piece of software based on the software information. (Supplementary Note 3) The device control unit (4) restricts the operation of software based on the impact of vulnerabilities. (Supplementary Note 4) The device control unit (4) restricts the operation of communication software based on the impact of vulnerabilities. (Supplementary Note 5) The device control unit (4) restricts the operation of software with vulnerabilities that have a high impact. (Supplementary Note 6) The device control unit (4) records the operating status of each piece of software whose operation has been individually restricted. (Supplementary Note 7) The control device (100) includes a software parts bill of materials storage unit (1) that stores a software parts bill of materials, and the software parts bill of materials storage unit (1) acquires a software parts bill of materials change request and change contents from a local software parts bill of materials management device (200), and updates the software parts bill of materials in accordance with the change request. (Supplementary Note 8) A computer-readable storage medium stores instructions that cause one or more processors to execute processing to accept a request to investigate vulnerabilities in software installed in a control device of an industrial machine, acquire a software parts bill of materials and vulnerability information for the software, investigate vulnerabilities in the software included in the control device, and restrict the operation of software that requires countermeasures.(Supplementary Note 9) The software parts bill management system (300) is connected to a control device (100) of an industrial machine via a local network, holds a software parts bill of the control device (100), and includes a software parts bill management device (200) that, when the software parts bill is changed, transmits a change request and details of the change to the control device (100) of the changed software parts bill, and a control device (100) that, when receiving the change request and details of the change from the software parts bill management device (200), updates the software parts bill in accordance with the change request.

[0059] REFERENCE SIGNS LIST 100 control device 1 SBOM storage unit 2 investigation request reception unit 3 vulnerability investigation unit 4 device control unit 200 SBOM management device 300 SBOM management system 111 CPU 112 ROM 113 RAM 114 non-volatile memory

Claims

1. A control device for industrial machinery, comprising: an investigation request receiving unit that receives an investigation request for vulnerabilities in software installed in the control device; a vulnerability investigation unit that obtains a software parts list and vulnerability information for the software and investigates vulnerabilities in the software; and a device control unit that restricts the operation of software that requires countermeasures.

2. The control device according to claim 1, wherein the vulnerability investigation unit obtains information about software installed in the control device from a software parts list, and obtains vulnerability information for each piece of software based on the software information.

3. The control device according to claim 1, wherein the device control unit restricts the operation of the software based on the impact of the vulnerability.

4. The control device according to claim 1, wherein the device control unit restricts the operation of the communication software based on the impact of the vulnerability.

5. The control device according to claim 1, wherein the device control unit restricts the operation of software having a vulnerability with a high impact.

6. The control device according to claim 5, wherein said device control section records the operating status of each piece of software whose operation has been individually restricted.

7. The control device according to claim 1, further comprising a software parts bill storage unit for storing a software parts bill, wherein the software parts bill storage unit acquires a change request and change details for the software parts bill from a local software parts bill management device, and updates the software parts bill in accordance with the change request.

8. A computer-readable storage medium that stores instructions to cause one or more processors to execute the following process: accept a request to investigate vulnerabilities in software installed in a control device of industrial machinery, obtain a software parts list and vulnerability information for said software, investigate vulnerabilities in the software included in said control device, and restrict the operation of software that requires countermeasures.

9. A software bill of materials management system including: a software bill of materials management device that is connected to a control device of an industrial machine via a local network, that holds a software bill of materials for the control device, and that, when the software bill of materials is changed, sends a software bill of materials change request and the details of the change to the control device of the changed software bill of materials; and a control device that, when it receives the change request and the details of the change from the software bill of materials management device, updates the software bill of materials in accordance with the change request.

Images