Security patch management system

Abstract

The objective of the present disclosure is to provide a technique for determining an order of application of a patch in consideration of severity of risk of patient harm (severity of harm × occurrence frequency) when vulnerability of software installed in a clinical examination device is exploited. A security patch management system according to the present disclosure determines an order in which a security patch is applied to software installed in a clinical examination device according to a magnitude of an influence in the case of occurrence of a risk and the probability of occurrence of the risk, and when the orders determined for two or more pieces of the software are the same, re-determines the order so that the software having greater influence in the case of occurrence of the risk is given an earlier order (refer to FIG. 10).

Description

Security Patch Management System

[0001] The present disclosure relates to a technique for managing security patches applied to software included in a clinical testing device.

[0002] When vulnerabilities are discovered in the operating systems (OS) or software installed in computers that control clinical testing equipment or embedded devices for analyzing blood samples, it becomes necessary to apply security patches (hereinafter referred to as patches) to prevent harm caused by exploiting the vulnerabilities. A security patch is a correction module that fixes vulnerabilities in software.

[0003] There are many patches for operating systems and software, and applying them all takes time, so patches for high-risk vulnerabilities must be applied first. A known risk analysis method is the "Risk Estimation Method Considering the Severity of Harm and the Probability of Occurrence (R-Map)" defined in the Medical Device Risk Management Standard (ISO 14971). When applying security patches, it is possible to prioritize patches based on the results of risk assessment using R-Map.

[0004] Patent Document 1 below discloses a method for prioritizing maintenance management tasks for a device (analytical device) that analyzes blood samples. In this document, a priority score is calculated based on the status of the analytical device. A high priority score is assigned to a maintenance management task that needs to be executed when a highly urgent condition (such as a non-responsive photometer) occurs. As described in this document, when applying security patches, a method can be considered for prioritizing patch application based on the status of the device caused by the problem and the urgency of the response.

[0005] Japanese Patent Application Laid-Open No. 2022-018100

[0006] In order to reduce the risk of patient harm (false reporting of measurement results due to data tampering, delayed reporting of measurement results due to equipment shutdowns) that may occur when vulnerabilities in the operating systems and software installed in computers that control clinical testing equipment and embedded devices for analyzing blood samples are exploited, it is necessary to prioritize vulnerabilities with high risk. The priority of patch application must also be determined based on this.

[0007] In Patent Document 1, the priority of maintenance management tasks is determined based on the severity of the condition of the analytical device caused by a problem. However, the priority does not take into account the risk of harm to the condition of the analytical device in the near future (severity of harm x frequency of occurrence). Furthermore, the priority does not reflect the magnitude of harm to patients, such as the length of time it takes to recover from a problem with the analytical device (delay in reporting measurement results).

[0008] The medical device risk management standard (ISO 14971) defines an R-Map that evaluates risk (severity of harm x frequency of occurrence) by dividing the severity of harm into five levels and the frequency of occurrence into six levels. Given that security incidents generally occur at a low frequency and that determining the severity of harm solely based on the loss of confidentiality, availability, and integrity (CIA) can result in biased scores, determining patch application priorities requires more detailed classification of the severity and frequency of harm based on the characteristics of clinical testing devices. Therefore, simply applying R-Map to patch application for clinical testing devices makes it difficult to appropriately prioritize patch application according to the characteristics of the devices.

[0009] The present disclosure has been made in consideration of the above-mentioned problems, and aims to provide a technology that determines the order in which patches are applied, taking into account the severity of the risk of harm to patients (severity of harm x frequency of occurrence) when a vulnerability in the software installed in a clinical testing device is exploited.

[0010] The security patch management system of the present disclosure determines the order in which security patches should be applied to software installed in a clinical testing device based on the magnitude of the impact if a risk occurs and the probability of the risk occurring, and if the orders determined for two or more of the software are the same, the order is re-determined so that the order is higher for the software with the greater impact if the risk occurs.

[0011] According to the security patch management system of the present disclosure, the order in which patches are applied can be determined taking into account the severity of the risk of patient harm (severity of harm x frequency of occurrence) if a vulnerability in the software installed in the clinical testing device is exploited.

[0012] 1 is a diagram illustrating the configuration of the security patch management system 1 and peripheral devices. FIG. 2 is a block diagram illustrating the internal configuration of the security patch management system 1. FIG. 3 is a diagram illustrating an example of a patch information input screen 30 that the patch information update processing unit 14 outputs to the administrator terminal 2. FIG. 4 shows an example of a score table 40 for calculating a second priority risk value 36. FIG. 5 shows an example of a product configuration information table 50 stored in the product configuration information storage unit 12. FIG. 6 shows an example of a risk combination table 60. FIG. 7 shows an example of an applied patch table 70. FIG. 8 shows an example of a patch application order table 80. FIG. 9 is a flowchart illustrating the process by which the patch information update processing unit 14 updates the first to third priority risk values. FIG. 10 is a flowchart illustrating the process by which the patch information update processing unit 14 updates the patch application order. FIG. 11 is an example of a patch application information search screen 110 that the patch information search processing unit 24 outputs to the security patch management system user terminal 3.

[0013] 1 is a diagram showing the configuration of a security patch management system 1 and peripheral devices according to an embodiment of the present disclosure. The security patch management system 1 is a system that manages security patches to be applied to software (OS, middleware, and other software) installed in a clinical testing device 4. The security patch management system 1 is connected to an administrator terminal 2, a security patch management system user terminal 3, and the clinical testing device 4 via a network 5.

[0014] 2 is a block diagram showing the internal configuration of the security patch management system 1. The security patch management system 1 includes a patch information storage unit 11, a product configuration information storage unit 12, a device information update processing unit 13, a patch information update processing unit 14 (patch information processing unit), and a patch information search processing unit 15 (patch information processing unit).

[0015] The patch information storage unit 11 stores patch information. The product configuration information storage unit 12 stores product configuration information. The device information update processing unit 13 stores data input from the clinical testing device 4 in the product configuration information storage unit 12. The patch information update processing unit 14 stores data input from the administrator terminal 2 in the patch information storage unit 11 and the product configuration information storage unit 12. The patch information search processing unit 15 searches the data stored in the patch information storage unit 11 and the product configuration information storage unit 12, and outputs the IDs of patches to be applied to the clinical testing device 4 and the order in which the patches should be applied to the security patch management system user terminal 3.

[0016] Since the patch information storage unit 11 and the product configuration information storage unit 12 store information about product vulnerabilities, in consideration of the risk of information leakage, the data may be stored in an encrypted state using a database encryption function.

[0017] 3 is a diagram showing an example of a patch information input screen 30 that the patch information update processing unit 14 outputs to the administrator terminal 2. The patch information input screen 30 is used by a user (patch administrator) of the administrator terminal 2 to input information about security patches to the security patch management system 1. The patch information input screen 30 has data input fields for a software name 31, version information 32, a vulnerability identifier 33, an applied patch ID 34, a first-priority risk value 35, and a second-priority risk value 36. The patch information input screen 30 also has an update button 37.

[0018] The software name 31 and version information 32 respectively store the name and version of the software installed in the clinical testing device 4. The vulnerability identifier 33 indicates an identifier that identifies a vulnerability that the software version has. The applied patch ID 34 indicates an ID that identifies a patch to address the vulnerability specified by the vulnerability identifier 33.

[0019] The first priority risk value 35 is a numerical representation of the risk of a vulnerability specified by the vulnerability identifier 33. The first priority risk value 35 is calculated by a general risk assessment method using, for example, the R-Map analysis method. The first priority risk value 35 is broadly divided into three categories: (a) unacceptable "A3 to A1", (b) unacceptable in principle but acceptable depending on cost and utility "B3 to B1", and (c) acceptable "C".

[0020] The second priority risk value 36 is an index for further refining the severity of risk for vulnerabilities that have the same first priority risk value 35. The patch manager manually calculates the second priority risk value from the score table shown in FIG. 4, which will be described later.

[0021] The patch manager enters this information on the patch information input screen 30 and presses the update button 37. The manager terminal 2 notifies the patch information update processor 14 of the entered information. The patch information update processor 14 stores the received information in the patch information storage unit 11 and the product configuration information storage unit 12.

[0022] 4 shows an example of a score table 40 for calculating the second-priority risk value 36. The score table 40 can be stored in advance in the patch information storage unit 11, for example, and presented to the administrator terminal 2. The score table 40 includes the ease with which an attacker can obtain vulnerability information (frequency of harm occurrence) 41, the corresponding frequency of occurrence score 42, the cause of a delay in reporting the measurement result (severity of harm) 43, the corresponding report delay score 44, the cause of an incorrect report of the measurement result (severity of harm) 45, and the corresponding incorrect report score 46. Generally, risk is calculated by combining the frequency of harm occurrence and the severity, so the second-priority risk value can be calculated as "frequency of harm score x (report delay score + incorrect report score)."

[0023] The occurrence frequency score 42 indicates that it is easier for an attacker to obtain vulnerability information, in descending order of score. In other words, the higher the occurrence frequency score 42, the higher the frequency of harm. The reporting delay score 44 indicates that the scale of business interruption (full or partial) involving the use of the clinical testing device 4 increases, and the time required to restore the clinical testing device 4 increases, in descending order of score. In other words, the higher the reporting delay score 44, the higher the severity of harm caused by delayed reporting of measurement results. The false reporting score 46 indicates that the severity of harm caused by false reporting of measurement results increases, in descending order of score. For example, if a malfunction of the analysis module included in the clinical testing device 4 prevents proper temperature control of the device and results in an abnormal measurement result, alarm information indicating the possibility of the abnormal measurement result is added to the measurement result, allowing the user to notice the abnormal value. On the other hand, if measurement results included in a database or communication message are tampered with, the customer will not notice the abnormal value, and the harm is considered to be greater than in the former case. Since an incorrect report of a measurement result poses a greater risk to a patient than a delayed report of a measurement result, the score value of the incorrect report score 46 is set higher than the score value of the delayed report score 44 .

[0024] 5 shows an example of a product configuration information table 50 stored in the product configuration information storage unit 12. The product configuration information table 50 includes a product serial number 51, a product unit name 52, a software name 53, version information 54, and a vulnerability identifier 55.

[0025] The product serial number 51 uniquely identifies the clinical testing apparatus 4. The product unit name 52 indicates the name of the unit that constitutes the clinical testing apparatus 4. The software name 53 is the name of the software installed in the unit. The version information 54 is the version of the software. The vulnerability identifier 55 is an identifier that identifies the vulnerability of the software and corresponds to the vulnerability identifier 33. Data in each field is automatically transferred from the clinical testing apparatus 4 to the apparatus information update processing unit 13, and the apparatus information update processing unit 13 stores (or updates) the data in the product configuration information table 50. The patch information update processing unit 14 automatically reflects the vulnerability identifier 33 in the vulnerability identifier 55. For example, the vulnerability identifier entered on the screen of Figure 3 can be identified using the software name and version information as keys.

[0026] 6 shows an example of a risk combination table 60. The risk combination table 60 holds definitions of combinations of first-priority risk values ​​and second-priority risk values. The risk combination table 60 can be stored in advance in the patch information storage unit 11.

[0027] The table 60 has a risk ID 61, a first priority risk value 62, and a second priority risk value 63. The risk ID 61 is an ID that uniquely identifies a combination of the first priority risk value 62 and the second priority risk value 63. The first priority risk value 62 and the second priority risk value 63 correspond to the first priority risk value 35 and the second priority risk value 36, respectively. The patch administrator stores possible combinations of the first priority risk value 62 and the second priority risk value 63 in the table 60 in advance.

[0028] 7 shows an example of an applied patch table 70. The applied patch table 70 holds combinations of risk IDs and applied patch IDs for vulnerability identifiers. The applied patch table 70 can be created in advance and stored in the patch information storage unit 11.

[0029] The applied patch table 70 has vulnerability identifiers 71, risk IDs 72, and applied patch IDs 73. Of the values ​​of vulnerability identifiers 55, values ​​with duplicates removed are reflected in the vulnerability identifiers 71. A risk ID 61 that is uniquely determined from the combination of first priority risk value 62 / second priority risk value 63 that matches the combination of first priority risk value 35 / second priority risk value 36 is reflected in the risk ID 72. The value of applied patch ID 34 is reflected in the applied patch ID 73 that is uniquely determined by the value of vulnerability identifier 71.

[0030] 8 shows an example of a patch application order table 80. The patch application order table 80 holds combinations of third-priority risk values ​​for applied patch IDs and patch application orders. The patch application order table 80 can be created in advance and stored in the patch information storage unit 11.

[0031] The patch application order table 80 has an applied patch ID 81, a third-priority risk value 82, a patch application order 83, and a patch application order 84. The applied patch ID 81 corresponds to the applied patch ID 73. The third-priority risk value 82 indicates the number of vulnerabilities that can be addressed with a single patch and have the largest second-priority risk value. The third-priority risk value 82, patch application order 83, and patch application order 84 are automatically calculated by the patch information update processing unit 14 according to the flows in FIGS. 9 and 10 , which will be described later. The patch application order 83 is calculated from the first to third-priority risk values. The patch application order 84 is a corrected value that takes ease of work into consideration.

[0032] 9 is a flowchart illustrating the process of updating the first to third priority risk values ​​by the patch information update processor 14. Each step in FIG. 9 will be described below.

[0033] Steps S90-S91: The patch information update processor 14 obtains the risk ID 61 of a record that matches the combination of the first-priority risk value 62 and the second-priority risk value 63 in Figure 6 from the first-priority risk value 35 and the second-priority risk value 36 on the patch information input screen 30. The obtained risk ID 61 is stored in or updated as the risk ID 72 in Figure 7.

[0034] Step S92: The patch information update processor 14 references all risk IDs 72 corresponding to the values ​​of the applied patch IDs 73 in Figure 7 and obtains all second-priority risk values ​​63 of records that match the risk IDs 61 in Figure 6. The number of the largest second-priority risk values ​​obtained is reflected in the third-priority risk value 82 in Figure 8. This number indicates how many risk IDs corresponding to the largest second-priority risk value can be addressed by applying the patch.

[0035] 10 is a flowchart illustrating the process of updating the patch application order by the patch information update processor 14. Each step is performed by the patch information update processor 14. Each step in FIG. 10 will be described below.

[0036] Step S100: Obtain a vulnerability identifier 55 corresponding to one of the product serial numbers 51 in FIG. 5 , and extract all applied patch IDs 73 for records that match the vulnerability identifier 71 with the same value. Extract all risk IDs 72 corresponding to each extracted applied patch ID, and extract the first-priority risk values ​​62 for records whose extracted risk ID matches the risk ID 61 in FIG. 6 . Determine the order of patch application in descending order of the first-priority risk values ​​62 included in each applied patch ID 73 (A3, A2, A1, B3, B2, B1, C in descending order of risk). In other words, since multiple first-priority risk values ​​62 are included for one patch, the order of application is determined based on the largest risk value among them. The order of patch application is reflected in the patch application order 83 in FIG. 8 .

[0037] Step S101: If there are multiple patches with the same value of the patch application order 83 in Fig. 8, execute step S102. If there are no patches with the same value, skip to step S105.

[0038] Step S102: Extract the values ​​of applied patch IDs 81 that have the same value for the patch application order 83 in FIG. 8. Extract the risk IDs 72 in FIG. 7 that correspond to the extracted applied patch IDs. Extract the values ​​of the second priority risk values ​​63 in FIG. 6 that correspond to the extracted risk IDs. Update the patch application order 83 in descending order of the second priority risk values ​​63 included for each applied patch ID. In other words, since multiple second priority risk values ​​63 are included for one patch, the application order is determined by the largest second priority risk value among them.

[0039] Step S103: If there are multiple patches with the same value of the patch application order 83 in Fig. 8, execute step S104. If there are no patches with the same value, skip to step S105.

[0040] Step S104: Extract the values ​​of the applied patch IDs 81 that have the same value of the patch application order 83 in Fig. 8. Update the patch application order 83 in descending order of the third priority risk value 82 among the vulnerabilities that can be addressed with one patch.

[0041] Step S105: Extract the vulnerability identifier 55 corresponding to each value of the product unit name 52 in Figure 5. Extract the applied patch ID 73 corresponding to the value of the vulnerability identifier 71 that corresponds to the extracted value of the vulnerability identifier 55. Correct the patch application order 83 of the extracted applied patch ID 73 so that it is consecutive for each value of the product unit name 52. The corrected application order is reflected in the patch application order 84.

[0042] 11 shows an example of a patch application information search screen 110 that the patch information search processing unit 24 outputs to the security patch management system user terminal 3. The patch application information search screen 110 has a product serial number input field 111 and a search button 112. The patch application information search screen 110 also displays a product serial number 113, a product unit 114, a software name 115, version information 116, an applied patch ID 117, and a patch application order 118 as search results.

[0043] Summary of the present disclosure The security patch management system 1 determines the order in which security patches are applied to software installed in the clinical testing device 4 according to the first priority risk value. This allows the application priority of security patches to be determined according to the magnitude of the impact and probability of occurrence of the risk caused by the vulnerability. Furthermore, if the orders once determined for two or more software programs are equal, the order is re-determined according to the second priority risk value. The second priority risk value is composed of the report delay score 44 and the false report score 46 (i.e., a numerical value representing the impact when a risk occurs). This allows an appropriate application order to be determined taking into account the magnitude of the impact of the risk, even when the order cannot be determined based on the magnitude of the impact and probability of occurrence of the risk.

[0044] The report delay score 44 is configured to indicate that the greater the scale of the outage of business using the clinical testing device 4, the greater the impact of the risk, and that the longer the time required to restore the clinical testing device 4, the greater the impact of the risk (see the middle section of Figure 4). This makes it possible to determine the order of patch application according to the degree of impact when the reporting of measurement results is delayed due to the occurrence of a risk. In other words, an appropriate order of patch application can be determined taking into account the characteristics of business using the clinical testing device 4.

[0045] The false reporting score 46 is configured to indicate that the greater the severity of the harm when a false report of a measurement result using the clinical testing device 4 occurs due to the occurrence of a risk, the greater the impact of the risk (see the lower part of Figure 4). This makes it possible to determine the order of patch application according to the degree of impact when a false report of a measurement result occurs due to the occurrence of a risk. In other words, an appropriate order of patch application can be determined taking into account the characteristics of the work using the clinical testing device 4.

[0046] When the orders determined based on the first and second priority risk values ​​are equal, the security patch management system 1 determines the application order so that the patch that can address the largest number of vulnerabilities is applied first. This allows for the priority of applying more effective security patches while slowing down the process of determining the application order based on the impact and probability of risk.

[0047] When the orders determined based on the first priority risk value, the second priority risk value, and the third priority risk value are equal, the security patch management system 1 determines the application order so that patches are applied to different software after successive patches to the same software have been applied, thereby improving the efficiency of patch application work.

[0048] <Regarding Modifications of the Present Disclosure> In the above-described embodiments, the targets to which security patches are applied are typically thought to be OS, middleware, firmware, etc., but are not limited to these, and the above-described embodiments can be applied to any software.

[0049] In the above embodiments, each functional unit (device information update processing unit 13, patch information update processing unit 14, patch information search processing unit 15) provided in the security patch management system 1 can be configured using hardware such as a circuit device that implements these functions, or can be configured by having a computing device such as a CPU (Central Processing Unit) execute software that implements these functions.

[0050] REFERENCE SIGNS LIST 1 Security patch management system 2 Administrator terminal 3 Security patch management system user terminal 4 Clinical testing device 5 Network 11 Patch information storage unit 12 Product configuration information storage unit 13 Device information update processing unit 14 Patch information update processing unit 15 Patch information search processing unit

Claims

1. A security patch management system that manages security patches to be applied to software installed in a clinical testing device, comprising: a memory unit that stores a first risk value that represents a risk caused by a vulnerability in the software; and a patch information processing unit that determines the order in which the security patches are to be applied to the clinical testing device, wherein the first risk value classifies the risk according to the magnitude of the impact if the risk occurs and the probability of the risk occurring, and the patch information processing unit determines the order according to the first risk value, thereby determining the order according to the magnitude of the impact if the risk occurs and the probability of the risk occurring, and when the orders determined according to the first risk values ​​for two or more of the software are equal, the patch information processing unit redetermines the order once determined for the two or more software so that the software with the greater impact if the risk occurs is given an earlier order.

2. The security patch management system described in claim 1, characterized in that, when the orders determined according to the first risk value for two or more of the software become equal, the patch information processing unit redetermines the order once determined for the two or more pieces of software so that the order is higher for the software with a higher probability of occurrence of the risk.

3. The security patch management system described in claim 2, characterized in that the memory unit stores a second risk value that quantifies the probability of the risk occurring, the second risk value is configured to indicate that the easier it is to obtain information about the vulnerability, the higher the probability of the risk caused by the vulnerability occurring, and the patch information processing unit redetermines the order in accordance with the second risk value, so that the higher the probability of the risk occurring, the earlier the order is.

4. The security patch management system of claim 1, characterized in that the memory unit stores a second risk value that quantifies the impact if the risk occurs, the second risk value is configured to indicate that the greater the scale of the stoppage of operations using the clinical testing equipment if the risk occurs, and the longer the time required to restore the clinical testing equipment if the risk occurs, the greater the impact, and the patch information processing unit redetermines the order in accordance with the second risk value, so that the greater the impact if the risk occurs, the earlier the order.

5. The security patch management system of claim 4, characterized in that the clinical testing device comprises a computer that controls the clinical testing device and an analysis module that performs analytical operations on samples, and the second risk value is configured to indicate that the impact of the computer stopping due to the occurrence of the risk is greater than the impact on the analysis module due to the occurrence of the risk.

6. The security patch management system of claim 1, characterized in that the memory unit stores a second risk value that quantifies the impact if the risk occurs, the second risk value is configured to indicate that the greater the severity of the harm when the occurrence of the risk causes an erroneous report of a measurement result using the clinical testing device, the greater the impact, and the patch information processing unit redetermines the order in accordance with the second risk value, so that the greater the impact if the risk occurs, the earlier the order is.

7. The security patch management system of claim 6, characterized in that the second risk value is configured to indicate that the impact is greater when alarm information indicating the possibility that the measurement result using the clinical testing device is an abnormal value is not attached to the measurement result than when alarm information is attached to the measurement result.

8. The security patch management system described in claim 1, characterized in that the memory unit stores a risk combination table in which the type of risk caused by the vulnerability is described by a combination of the first risk value and a second risk value that quantifies at least one of the probability of the risk occurring or the impact if the risk occurs, the patch information processing unit obtains the second risk value combined with the first risk value from the risk combination table, and the patch information processing unit redetermines the order in accordance with the second risk value obtained from the risk combination table.

9. The security patch management system of claim 2, characterized in that: the memory unit stores the number of vulnerabilities that can be addressed by applying one of the security patches as a first number; the patch information processing unit, when the orders determined according to the first risk values ​​for two or more of the software are equal, redetermines the order once determined for the two or more pieces of software so that the higher the probability of the risk occurring or the higher the impact if the risk occurs, the earlier the order; and when the redetermined orders are again equal, the patch information processing unit a third time re-determines the redetermined order so that the security patch with the larger first number is given an earlier order.

10. The security patch management system of claim 9, wherein the memory unit stores a risk combination table describing the type of risk caused by the vulnerability by a combination of the first risk value and a second risk value that quantifies at least one of the probability of the risk occurring or the impact if the risk occurs; the patch information processing unit obtains from the combination table the number of the largest of the second risk values ​​that constitute the type of risk that can be addressed by applying the security patch as a second number; and the patch information processing unit stores the second number in the memory unit as the first number.

11. The security patch management system of claim 1, characterized in that, when there are multiple security patches to be applied to the same software in the determined order, the patch information processing unit redetermines the determined order so that after successive application of the security patches to the same software has been completed, the security patches are applied to another piece of software.

Images