Security patch management system

Abstract

The purpose of this disclosure is to provide a technique for determining the priority of patch application when a vulnerability in the software installed on a clinical examination device is maliciously exploited, taking into account the severity of the risk to the patient (severity of the risk × frequency of occurrence). The security patch management system disclosed herein determines the priority of applying security patches to the software installed on the clinical examination device based on the magnitude of the impact of the risk and the probability of the risk occurring. When the priority is the same for two or more software programs, the priority is re-determined so that the greater the impact of the risk, the higher the priority (see Figure 10).

Description

Technical Field

[0001] This disclosure relates to a technique for managing security patches for software applications used in clinical testing devices. Background Technology

[0002] When vulnerabilities are discovered in the operating system (OS) or software running on computers controlling clinical testing devices or embedded devices used to analyze blood samples, security patches (hereinafter referred to as patches) must be applied to prevent these vulnerabilities from being maliciously exploited and causing harm. Security patches are patching modules used to correct vulnerabilities in software.

[0003] The operating system or software may have numerous patches, and applying them all would be time-consuming. Therefore, patches targeting higher-risk vulnerabilities must be prioritized. For risk analysis methods, the "R-Map" method, which considers the severity and probability of occurrence of hazards, is known in the Medical Device Risk Management Standard (ISO 14971). When applying security patches, the priority of patches can be determined based on the risk assessment results of the R-Map.

[0004] Patent Document 1 discloses a method for prioritizing maintenance and management tasks of a device for analyzing blood samples (analytical equipment). In this document, a priority score is calculated based on the status of the analytical equipment. When a highly urgent situation occurs (e.g., a photometer not responding), the maintenance and management tasks to be performed are assigned a higher priority score. As described in this document, when applying security patches, the priority of patch application can also be considered based on the status of the equipment caused by the malfunction and the urgency of the response.

[0005] Existing technical documents

[0006] Patent documents

[0007] Patent Document 1: Japanese Patent Application Publication No. 2022-018100 Summary of the Invention

[0008] The technical problem that the invention aims to solve

[0009] When controlling clinical testing equipment, to minimize patient harm caused by malicious exploitation of vulnerabilities in the operating system or software of embedded devices used for blood sample analysis (such as data tampering leading to false reporting of measurement results, or device shutdown causing delays in reporting measurement results), high-risk vulnerabilities must be addressed first. The priority of patch application must be determined accordingly.

[0010] Patent Document 1 prioritizes maintenance and management tasks based on the severity of the analytical equipment's condition caused by a malfunction. However, it does not consider the risk of harm caused by the analytical equipment's condition in the near future (severity of harm × frequency of occurrence). Furthermore, the magnitude of patient harm, such as the recovery time when the analytical equipment malfunctions (reporting delay of measurement results), is not reflected in the prioritization.

[0011] The ISO 14971 standard for medical device risk management specifies an R-Map for evaluating risk (severity of hazard × frequency of occurrence), which categorizes hazard severity into five levels and frequency of occurrence into six levels. Given the generally low frequency of safety incidents, and the potential bias in severity scores when considering only CIA (confidentiality, availability, and integrity) losses, a more detailed classification must be applied, combining hazard severity and frequency benchmarks with the characteristics of the clinical testing device, when determining patch application priorities. Therefore, simply applying the R-Map to patch applications for clinical testing devices is insufficient to achieve a suitable patch application priority that matches the characteristics of the clinical testing device.

[0012] This disclosure is made in response to the above problems, and its purpose is to provide a technique for determining the priority of patch application based on the depth of the risk of harm to patients (severity of harm × frequency of occurrence) when a vulnerability in the software installed on a clinical examination device is maliciously exploited.

[0013] Technical means for solving technical problems

[0014] The security patch management system disclosed herein determines the priority of applying security patches to the software mounted on the clinical examination device based on the magnitude of the impact of the risk when it occurs and the probability of the risk occurring. When the priority is the same for two or more software, the priority is re-determined so that the greater the impact of the risk when it occurs, the higher the priority.

[0015] Invention Effects

[0016] According to the security patch management system disclosed herein, when a vulnerability in the software installed on a clinical examination device is maliciously exploited, the application priority of patches can be determined by considering the depth of the risk to patients (severity of harm × frequency of occurrence). Attached Figure Description

[0017] Figure 1 This is a diagram showing the structure of the security patch management system 1 and its peripheral equipment.

[0018] Figure 2This is a block diagram showing the internal structure of the security patch management system 1.

[0019] Figure 3 This is a diagram showing an example of the patch information input screen 30 output by the patch information update processing unit 14 to the administrator terminal 2.

[0020] Figure 4 An example of a scoring table 40 is shown for calculating the second priority risk value 36.

[0021] Figure 5 An example of a product structure information table 50 stored in the product structure information storage unit 12 is shown.

[0022] Figure 6 An example of risk portfolio table 60 is shown.

[0023] Figure 7 An example of applying patch table 60 is shown.

[0024] Figure 8 An example of patch application priority table 80 is shown.

[0025] Figure 9 This is a flowchart showing the patch information update processing unit 14 updating the first to third priority risk values.

[0026] Figure 10 This is a flowchart showing the order of patch application updates by the patch information update processing unit 14.

[0027] Figure 11 This is an example of a patch application information retrieval screen 110 output by the patch information retrieval processing unit 24 to the security patch management system via terminal 3. Detailed Implementation

[0028] Figure 1 This diagram illustrates the structure of the security patch management system and peripheral devices according to an embodiment of this disclosure. The security patch management system 1 is a system for managing security patches applied to the software (OS, middleware, other software) mounted on the clinical examination device 4. The security patch management system 1 is connected to the administrator terminal 2, the security patch management system utilization terminal 3, and the clinical examination device 4 via a network 5.

[0029] Figure 2 This is a block diagram showing the internal structure of the security patch management system 1. The security patch management system 1 includes a patch information storage unit 11, a product structure 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 retrieval processing unit 15 (patch information processing unit).

[0030] The patch information storage unit 11 stores patch information. The product structure information storage unit 12 stores product structure information. The device information update processing unit 13 stores the data input from the clinical examination device 4 into the product structure information storage unit 12. The patch information update processing unit 14 stores the data input from the administrator terminal 2 into both the patch information storage unit and the product structure information storage unit 12. The patch information retrieval processing unit 15 retrieves the data stored in the patch information storage unit 11 and the product structure information storage unit 12, and outputs the ID of the patch applicable to the clinical examination device 4 and the application priority of the patch to the security patch management system terminal 3.

[0031] Since the patch information storage unit 11 and the product structure information storage unit 12 are used to store information related to product vulnerabilities, the risk of information leakage can be considered, and the data can be saved in an encrypted state through the database encryption function.

[0032] Figure 3 This shows an example of a patch information input screen 30 output by the patch information update processing unit 14 to the administrator terminal 2. The patch information input screen 30 is an interface used by the user (patch manager) of the administrator terminal 2 to input security patch-related information into the security patch management system 1. The patch information input screen 30 has software name 31, version information 32, vulnerability identifier 33, application patch ID 34, first priority risk value 35, and second priority risk value 36 as data input fields. The patch information input screen 30 also has an update button 37.

[0033] Software name 31 and version information 32 store the software name and version installed on the clinical testing device 4, respectively. Vulnerability identifier 33 indicates an identifier that identifies a vulnerability present in this software version. Application patch ID 34 indicates the ID of the patch used to address the vulnerability specified by vulnerability identifier 33.

[0034] The first priority risk value 35 is a numerical representation of the risk of the vulnerability specified by vulnerability identifier 33. The first priority risk value 35 can be calculated, for example, using a general risk assessment method employing R-Map analysis. The first priority risk value 35 is divided into three categories: (a) unacceptable “A3–A1”; (b) unacceptable in principle but acceptable based on cost or utility “B3–B1”; and (c) acceptable “C”.

[0035] The second priority risk value of 36 is an indicator used to further detail the severity of risks associated with vulnerabilities that are identical to the first priority risk value of 35. Patch administrators will use this information as described later. Figure 4 The second priority risk value is calculated manually from the score sheet.

[0036] 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 processing unit 14 of the entered information. The patch information update processing unit 14 stores the received information in the patch information storage unit and the product structure information storage unit 12.

[0037] Figure 4 An example of a scoring table 40 for calculating the second priority risk value 36 is shown. The scoring table 40 is, for example, pre-stored in the patch information storage unit 11 and can be displayed to the administrator terminal 2. The scoring table 40 includes: the ease with which an attacker can obtain vulnerability information (frequency of occurrence of the harm) 41, its corresponding frequency score 42, the reason for the delay in reporting measurement results (severity of the harm) 43, its corresponding reporting delay score 44, the reason for false reporting of measurement results (severity of the harm) 45, and its corresponding false reporting score 46. Generally, risk is calculated by combining the frequency of occurrence of the harm with its severity; therefore, the second priority risk value can be calculated as "frequency of occurrence score × (reporting delay score + false reporting score)".

[0038] The frequency of occurrence score (42), ranked from highest to lowest, indicates situations where attackers can easily obtain vulnerability information. In other words, the higher the frequency of occurrence score (42), the higher the frequency of the harm. The reporting delay score (44), ranked from highest to lowest, indicates situations where the scale of service interruption (complete or partial) using the clinical examination device 4 is large and the time required to restore the device is long. In other words, the reporting delay score (44), ranked from highest to lowest, indicates situations where the severity of the harm caused by delayed measurement results increases. The false report score (46), ranked from highest to lowest, indicates situations where the severity of the harm caused by false reports of measurement results is high. For example, if the analysis module of the clinical examination device 4 malfunctions, causing the device's temperature control to malfunction and the measurement result to become an anomaly, an alarm message indicating the possibility of the measurement result becoming an anomaly can be added to the measurement result so that the user can notice the anomaly. On the other hand, if the measurement result contained in the database or communication message is tampered with, the customer may not notice the anomaly and therefore perceive the harm as greater than the former. Since false reporting of measurement results is more harmful to patients than delayed reporting of measurement results, the score for false reporting (46) is set higher than the score for delayed reporting (44).

[0039] Figure 5 An example of a product structure information table 50 stored in the product structure information storage unit 12 is shown. The product structure information table 50 has a product serial number 51, a product unit name 52, a software name 53, version information 54, and a vulnerability identifier 55.

[0040] Product serial number 51 uniquely identifies the clinical examination device 4. Product unit name 52 indicates the name of the unit constituting the clinical examination device 4. Software name 53 is the name of the software installed on the unit. Version information 54 is the version of the software. Vulnerability identifier 55 is an identifier that identifies vulnerabilities in the software, corresponding to vulnerability identifier 33. The data in each field is automatically transmitted from the clinical examination device 4 to the device information update processing unit 13, and the device information update processing unit 13 stores (or updates) the data in the product structure information table 50. Patch information update processing unit 14 can automatically reflect vulnerability identifier 33 to vulnerability identifier 55. For example, the software name and version information can be used as keys in... Figure 3 The screen displays the vulnerability identifier that was entered.

[0041] Figure 6 An example of risk combination table 60 is shown. Risk combination table 60 stores the combination definition of a first priority risk value and a second priority risk value. Risk combination table 60 can be pre-stored in the storage patch information storage unit 11.

[0042] Table 60 contains a risk ID 61, a first priority risk value 62, and a second priority risk value 63. Risk ID 61 uniquely identifies the 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 manager pre-stores the possible combinations of the first priority risk value 62 and the second priority risk value 63 in Table 60.

[0043] Figure 7 An example of an application patch table 70 is shown. The application patch table 70 stores a combination of a risk ID corresponding to a vulnerability identifier and an application patch ID. The application patch table 70 can be pre-created and stored in the patch information storage unit 11.

[0044] Application patch table 70 contains vulnerability identifier 71, risk ID 72, and application patch ID 73. The value of vulnerability identifier 55, after removing duplicates, is reflected in vulnerability identifier 71. Risk ID 61, uniquely determined by the combination of first priority risk value 62 and second priority risk value 63, which is consistent with the combination of first priority risk value 35 and second priority risk value 36, is reflected in risk ID 72. Application patch ID 73, uniquely determined by the value of vulnerability identifier 71, can reflect the value of application patch ID 34.

[0045] Figure 8An example of patch application priority table 80 is shown. Patch application priority table 80 stores a combination of the third priority risk value corresponding to the applied patch ID and the patch application priority. Patch application priority table 70 can be pre-created and stored in the patch information memory unit 11.

[0046] The patch application priority table 80 includes patch ID 81, third priority risk value 82, patch application priority 83, and patch application priority 84. Patch ID 81 corresponds to patch ID 73. The third priority risk value 82 indicates the number of vulnerabilities with the highest second priority risk value among those vulnerabilities that can be addressed by a single patch. The third priority risk value 82, patch application priority 83, and patch application priority 84 are processed by the patch information update processing unit 14 according to the following... Figures 9 to 10 The process is automatically calculated. Patch application priority 83 is calculated based on the first to third priority risk values. Patch application priority 84 is a value that has been adjusted to take into account operational convenience.

[0047] Figure 9 This is a flowchart illustrating the process by which the patch information update processing unit 14 updates the first to third priority risk values. The following is a description of... Figure 9 The steps are explained below.

[0048] Steps S90-S91: The patch information update processing unit 14 obtains the first priority risk value 35 and the second priority risk value 36 based on the patch information input screen 30. Figure 6 The risk ID 61 recorded is consistent with the combination of the first priority risk value 62 and the second priority risk value 63. The acquired risk ID 61 is stored or updated to... Figure 7 Risk ID27.

[0049] Step S92: Patch information update processing unit 14 (refer to) Figure 7 Get all risk IDs 72 corresponding to application patch ID 73. Figure 6 All second-priority risk values ​​63 recorded that match risk ID 61. Among the acquired second-priority risk values, the number of the highest risk values ​​is reflected in... Figure 8 The third priority risk value is 82. This number indicates how many risk IDs corresponding to the highest second priority risk value can be processed by applying this patch.

[0050] Figure 10 This is a flowchart illustrating the process of the patch information update processing unit 14 updating the patch application priority. Each step is performed by the patch information update processing unit 14. The following will describe... Figure 10 The steps are explained below.

[0051] Step S100: Obtain and Figure 5For each product serial number 51, a vulnerability identifier 55 is identified, and all application patch IDs 73 corresponding to the records with the same vulnerability identifier 71 are extracted. For each extracted application patch ID, the values ​​of all corresponding risk IDs 72 are extracted, and the extracted risk IDs are compared with... Figure 6 The first priority risk value 62 of the record consistent with risk ID 61 is extracted. The application order of patches is determined based on the descending order of the first priority risk values ​​62 contained in each patch ID 73 (risk from highest to lowest: A3, A2, A1, B3, B2, B1, C). In other words, since a patch contains multiple first priority risk values ​​62, the application order is determined according to the largest risk value. The application order of patches is reflected in... Figure 8 The patch application order is 83.

[0052] Step S101: In Figure 8 If multiple patches with the same value at patch application priority 83 exist, proceed to step S102. Figure 8 If there are no multiple patches with the same value as patch application priority 83, proceed to step S105.

[0053] Step S102: Extraction Figure 8 The value of application patch ID 81 is the same as the value of patch application priority 83. Extract the value corresponding to the extracted application patch ID. Figure 7 Risk ID 72. Extract the corresponding risk ID. Figure 6 The value of the second priority risk value 63. The patch application priority 83 is updated in descending order of the second priority risk values ​​63 contained in each application patch ID. That is, since a patch contains multiple second priority risk values ​​63, the application priority is determined by the largest second priority risk value.

[0054] Step S103: In Figure 8 If multiple patches have the same value as patch application priority 83, proceed to step S104. Figure 8 If there are no multiple patches with the same value as patch application priority 83, proceed to step S105.

[0055] Step S104: Extract Figure 8 The value of patch application priority 83 is the same as the value of patch ID 81. For vulnerabilities that can be addressed by a single patch, patch application priority 83 is updated in descending order of the third priority risk value 82.

[0056] Step S105: Extraction and Figure 5The vulnerability identifier 55 corresponds to the value of each product unit name 52. Based on the value of the vulnerability identifier 71 corresponding to the extracted vulnerability identifier 55, the corresponding application patch ID 73 is extracted. For the patch application sequence 83 of the extracted application patch ID 73, it is corrected according to the value of each product unit name 52 to ensure continuity. The corrected application sequence is reflected in the patch application sequence 84.

[0057] Figure 11 This illustrates an example of a patch application information retrieval screen 110 output by the patch information retrieval processing unit 24 to the security patch management system via terminal 3. The patch application information retrieval screen 110 has an input field 11 for the product serial number and a search button 112. The patch application information retrieval screen 110 displays the product serial number 113, product unit 114, software name 115, version information 116, application patch ID 117, and patch application sequence 118 as search results.

[0058] This is a summary of the disclosure.

[0059] The security patch management system 1 determines the priority of security patches applied to the software mounted on the clinical testing device 4 based on a first priority risk value. This allows the application priority of security patches to be determined according to the impact and probability of the risk caused by the vulnerability. Furthermore, if the temporarily determined priorities for two or more software programs are the same, the priority is re-determined based on a second priority risk value. The second priority risk value consists of a report delay score 44 and a false report score 46 (i.e., a numerical value representing the impact when the risk occurs). Therefore, even when the priority cannot be determined based on the impact and probability of the risk, an appropriate application priority can be determined based on the impact of the risk.

[0060] The report delay score of 44 is defined as indicating that the larger the scale of the business interruption using clinical examination equipment 4, the greater the risk impact, and the longer the time required to restore clinical examination equipment 4, the greater the risk impact (see reference). Figure 4 (Middle paragraph) Thus, the priority of patch application can be determined based on the degree of impact when the reporting of measurement results is delayed due to the occurrence of risks. In other words, the appropriate priority of patch application can be determined by taking into account the characteristics of the operations of Clinical Examination Device 4.

[0061] The false report score of 46 is defined as indicating the greater the severity of the harm caused by a false report of the measurement results from the clinical examination device 4 due to the occurrence of the risk, the greater the impact of the risk (see [reference]). Figure 4(See the following paragraph). Therefore, the priority of patch application can be determined based on the extent of the impact when a risk leads to a false report in the measurement results. In other words, the appropriate priority of patch application can be determined by considering the characteristics of the services provided by Clinical Examination Device 4.

[0062] When the priority determined by the first and second priority risk values ​​are the same, the security patch management system 1 determines the priority to apply patches that address more vulnerabilities first. This reduces the reliance on risk severity and probability of occurrence to determine application priority, while prioritizing the application of more effective security patches.

[0063] The security patch management system 1 determines the application priority when the priorities determined by the first, second, and third priority risk values ​​are the same. This ensures that patches are applied to other software only after the same software has been patched consecutively. This improves the efficiency of patch application.

[0064] Variations of this disclosure

[0065] In the above implementation, the typical objects for applying security patches are OS, middleware, firmware, etc., but are not limited to these, and the above implementation can also be applied to any software.

[0066] In the above embodiments, the functional units (device information update processing unit 13, patch information update processing unit 14, and patch information retrieval processing unit 15) of the security patch management system 1 can be composed of hardware such as circuit devices with these functions installed, or they can be composed of software with these functions installed executed by a computing device such as a CPU (Central Processing Unit).

[0067] Label Explanation

[0068] 1. Security Patch Management System

[0069] 2. Administrator Terminal

[0070] 3. Security Patch Management System utilizes terminals

[0071] 4. Clinical examination devices

[0072] 5 Networks

[0073] 11 Patch Information Storage Department

[0074] 12 Product Structure Information Storage Department

[0075] 13. Device Information Update Processing Department

[0076] 14 Patch Information Update Processing Department

[0077] Patch 15 Information Retrieval and Processing Department.

Claims

1. A security patch management system for managing security patches for software applications in clinical examination devices, characterized in that, include: A storage unit is used to store a first risk value representing the risk arising from a vulnerability in the software; as well as The patch information processing unit is used to determine the order in which the security patch is applied to the clinical examination device. The first risk value is obtained by distinguishing the risks based on the degree of impact when the risks occur and the probability of the risks occurring. The patch information processing unit determines the priority based on the first risk value, thereby determining the priority according to the degree of impact and the probability of the risk occurring. If two or more software programs have the same priority based on the first risk value, the patch information processing unit will re-determine the temporary priority of the two or more software programs so that the greater the impact of the risk, the higher the priority.

2. The security patch management system according to claim 1, characterized in that, If two or more software programs have the same priority based on the first risk value, the patch information processing unit will re-determine the temporary priority of the two or more software programs so that the higher the probability of the risk occurring, the higher the priority.

3. The security patch management system according to claim 2, characterized in that, The storage unit stores a second risk value, which is a numerical representation of the probability of the risk occurring. This 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 arising from that vulnerability occurring. The patch information processing unit re-determines the priority based on the second risk value, so that the higher the probability of the risk occurring, the higher the priority.

4. The security patch management system according to claim 1, characterized in that, The storage unit stores a second risk value, which is obtained by quantifying the impact of the risk when it occurs. The second risk value is configured to indicate that the greater the scale of service disruption using the clinical examination device when the risk occurs, the greater the impact; and the longer the time required for the clinical examination device to resume operation when the risk occurs, the greater the impact. The patch information processing unit re-determines the priority based on the second risk value, so that the greater the impact of the risk when it occurs, the higher the priority.

5. The security patch management system according to claim 4, characterized in that, The clinical examination device includes a computer that controls the clinical examination device and an analysis module that performs analysis operations on samples. 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 of the analysis module presenting data due to the occurrence of the risk.

6. The security patch management system according to claim 1, characterized in that, The storage unit stores a second risk value, which is obtained by quantifying the impact of the risk when it occurs. The second risk value is configured to indicate that the greater the severity of the harm caused by the occurrence of the risk, resulting in a false report of the measurement results from the use of the clinical examination device, the greater the impact. The patch information processing unit re-determines the priority based on the second risk value, so that the greater the impact of the risk when it occurs, the higher the priority.

7. The security patch management system according to claim 6, characterized in that, The second risk value is configured to indicate that the impact is greater without additional alarm information than when an alarm message indicating the possibility that the measurement result using the clinical examination device is an outlier is attached to the measurement result.

8. The security patch management system according to claim 1, characterized in that, The storage unit stores a risk combination table, which describes the category of risk arising from the vulnerability through a combination of the following values: The first risk value; as well as A second risk value is obtained by quantifying at least one of the probability of the risk occurring and the impact of the risk when it occurs. The patch information processing unit obtains the second risk value combined with the first risk value from the risk combination table; The patch information processing unit re-determines the priority based on the second risk value obtained from the risk combination table.

9. The security patch management system according to claim 2, characterized in that, The storage unit stores the number of vulnerabilities that can be addressed by applying one of the security patches, as a first quantity. If two or more software programs have the same priority based on the first risk value, the patch information processing unit will re-determine the temporary priority of the two or more software programs, so that the higher the probability of the risk occurring and the greater the impact of the risk when it occurs, the higher the priority. If the re-determined priority is the same again, the patch information processing unit will re-determine the priority again, so that the more numerous the security patches are, the higher their priority will be.

10. The security patch management system according to claim 9, characterized in that, The storage unit stores a risk combination table, which describes the category of risk arising from the vulnerability through a combination of the following values: The first risk value; as well as A second risk value is obtained by quantifying at least one of the probability of the risk occurring and the impact of the risk when it occurs. The patch information processing unit obtains from the combination table the largest number of the second risk values ​​among the categories of risks that can be addressed by applying the security patch, as the second number. The patch information processing unit stores the second quantity as the first quantity in the storage unit.

11. The security patch management system according to claim 1, characterized in that, When the patch information processing unit determines that there are multiple security patches that should be applied to the same software in the determined order, it re-determines the determined order so that after the security patches are applied to the same software consecutively, the security patches are applied to other software.

Images