System and method for scoring and charging service requests generated by third party network monitoring tools

Abstract

A non-transient computer-readable medium (16) stores instructions that can be read and executed by at least one electronic processor (14) to perform a method for reducing the burden of false positive information technology (IT) vulnerability alerts on a service processing system (1). The method includes: identifying a service request (11) received by the service processing system as an IT vulnerability alert from a monitoring tool for a medical device (10), the IT vulnerability alert being generated by an IT vulnerability monitoring tool operated to monitor an IT network to which the medical device is connected; implementing a remediation process for the vulnerability alert from the monitoring tool; repeatedly identifying and implementing the remediation to accumulate statistics on the vulnerability alerts from the monitoring tool; and outputting an indication (26) if the statistics indicate that the vulnerability alerts from the monitoring tool are placing an unacceptable burden on the service processing system.

Description

Technical Field

[0001] The following content generally covers the fields of medical equipment maintenance, medical equipment safety, and related fields. Background Technology

[0002] Many medical devices are computerized. Some examples include medical imaging equipment such as magnetic resonance imaging (MRI) scanners, computed tomography (CT) scanners, positron emission tomography (PET) scanners, ultrasound imaging systems, etc.; image-guided therapy (IGT) systems that use such medical imaging equipment; patient monitors; mechanical ventilators, etc. Computerized medical devices should employ appropriate data security measures for many reasons, such as: protecting sensitive patient medical data collected or processed by the medical device; ensuring that unauthorized personnel do not operate (or interfere with) the medical device; ensuring the integrity and safe operation of the medical device; and ensuring that the medical device does not provide an entry point for unauthorized access to the hospital's electronic data network to which it is connected.

[0003] Computerized medical devices (e.g., medical imaging equipment) are connected to hospital electronic networks. Therefore, cybersecurity considerations apply to medical devices, protecting them from attacks and preventing them from acting as access points for cyberattacks. Medical devices are also often highly configurable, with different software packages deployed to provide different combinations of functionality; therefore, vulnerabilities for cyberattacks can vary depending on the installation. Software packages for medical devices can include medical task-specific software developed internally or purchased from vendors, and typically also include general-purpose software such as operating system (OS) software, device firmware loaded onto general peripherals or other devices, device drivers, etc. General-purpose software can be streamlined by removing modules or components irrelevant to the operation of the medical device. Every piece of software in the entire software package of a medical device can introduce cyberattack vulnerabilities, and in some cases, the existence and exploitability of a vulnerability may depend on the combination of software that makes up the entire package, or on whether an optional component is included.

[0004] Medical device vendors remain vigilant to patch any vulnerabilities that may be identified. Maintaining cybersecurity is an ongoing process, as new vulnerabilities are constantly being identified and security packages are continuously released. Vendors typically push these patches to customers via the internet (potentially through the hospital's IT network or other internet-connected on-premises IT infrastructure).

[0005] Suppliers also strive to provide customer-friendly problem-reporting channels for customers to request assistance with medical devices, such as through a maintenance call center (which customers might call to report problems with their medical devices), or through websites or dedicated software with application programming interfaces (APIs) for reporting issues. While these channels are primarily intended for customers to report operational problems (such as medical device malfunctions or unsatisfactory performance), it has been found that customers also utilize these channels to report software vulnerabilities and request remediation for them. This is not necessarily a problem; in fact, customers can identify vulnerabilities before the medical device supplier, especially when the vulnerability relates to generic software purchased by the supplier. In some instances, customers may receive vulnerability notifications before the supplier does.

[0006] Given the sheer volume of software and countless potential vulnerabilities, public and private vulnerability databases are currently maintained. For example, the Common Vulnerability Disclosures (CVEs) are publicly accessible databases of cybersecurity vulnerabilities. Many companies now offer passive network scanning products that run in the background. These passive scanners (also referred to as monitoring tools in this document) collect information about the software running on electronic networks (e.g., hospital networks) and continuously check the software against vulnerability databases to automatically detect potential vulnerabilities. This is typically handled by the hospital's information technology (IT) department, whose staff may have limited familiarity with the software packages of medical devices. When IT personnel receive notification of a potential vulnerability in the software of a medical device from a passive scanner, they can report the vulnerability to the medical device vendor through the provided issue reporting channels and expect the vendor to respond quickly with an appropriate security patch or other solution.

[0007] However, passive scanners can produce a high rate of false positives, reporting vulnerabilities that don't actually exist in a specific instance of the scanned software. This can be a result of limited information gathered through passive scanning, overly inclusive reporting, and other methods. For example, a passive scanner might identify that a medical device is using operating system version 2.1 (as an example), and the database indicates a cybersecurity vulnerability in operating system version 2.1. The passive scanner reports the vulnerability, and hospital IT staff can then submit a remediation request to the vendor to fix it. However, the medical device might actually be using a simplified implementation of operating system version 2.1 with limited functionality sufficient to run the medical device, and the reported vulnerability might not actually exist in the simplified implementation of operating system version 2.1 or be unexploitable in the simplified implementation of operating system version 2.1 running on the medical device. In another scenario, a passive scanner might be configured to automatically submit a remediation request directly to the medical device vendor without the knowledge or action of hospital IT staff. Again, due to the high rate of false positives generated by passive scanners, this could result in a high rate of incorrect and unnecessary remediation requests being submitted to the vendor.

[0008] It has been found that hospitals using passive scanners are submitting high rates of false positive vulnerability remediation requests to medical device vendors. These high false positive rates can overburden vendor service personnel and may divert their time from resolving actual issues with the medical devices. However, vendors cannot ignore vulnerability remediation requests, as doing so could lead to customer dissatisfaction and potentially miss actual vulnerabilities.

[0009] The following section discloses some improvements to overcome these and other problems.

[0010] Document US2017 / 034200A1 discloses a defect remediation management server, or "defect server," that receives defect data from multiple defect sources. The defect server analyzes and correlates the defect data to generate a defect record for each asset and for each defect. The defect server prioritizes the defect records and stores them, along with additional information associated with each defect record, in a defect database. The defect server then groups the defect records in the defect database into one or more work items based on grouping criteria. Furthermore, the defect server calculates a work priority score for each work item and assigns it to each work item. In response, the defect server generates instructions based on the work priority scores to create, update, and / or cancel remediation tickets for each work item. Additionally, the defect server generates interactive defect remediation reports and / or dashboards based on the defect records for presentation to the user.

[0011] Document US10873596B1 discloses a computerized method for interfacing with security hardware devices, which is used to evaluate potential remedial actions in response to potential information security threats by: automatically ingesting and parsing incoming alerts from security hardware devices; automatically extracting relevant data elements from the alerts; supplementing the alerts with the extracted information by querying and retrieving from other systems; automatically ranking the alerts according to importance by using an engine that combines the information; and issuing commands to automatically take remedial, containment, or other programmed actions against the alerts.

[0012] Frame, A.'s paper "Set, Triage, and Improve: Strategies for Tuning-out False positives" (September 19, 2022, retrieved from the Internet URL: https: / / web.archive.org / web / 20230528230703 / https: / / www.netskope.com / blog / set-triage-and-improve-strategies-for-tuning-out-false-positives) discloses a technique for prioritizing security alerts. Summary of the Invention

[0013] In one aspect, a service processing system includes: a client interface via which service requests related to a medical device are received from a client; a service information technology (IT) system configured to dispatch service requests to service personnel and track the resolution of service requests; and an electronic processor programmed to perform a method for monitoring service requests related to IT vulnerability alerts, the method comprising: identifying service requests for IT vulnerability alerts as a source of a monitoring tool, wherein the service requests include reports of IT vulnerabilities in the medical device received by the client interface from an IT vulnerability monitoring tool, the IT vulnerability monitoring tool operating to monitor an IT network to which the medical device is connected; calculating the burden imposed on the service processing system by the IT vulnerability alerts from the monitoring tool; and performing remedial actions in response to the burden imposed on the service processing system by the IT vulnerability alerts from the monitoring tool received from a given client satisfying an overload criterion.

[0014] In another aspect, a non-transient computer-readable medium stores instructions that can be read and executed by at least one electronic processor to perform a method for reducing the burden of false-positive IT vulnerability alerts on a service processing system. The method includes: identifying a service request received by the service processing system as an IT vulnerability alert originating from a monitoring tool for a medical device, the IT vulnerability alert being generated by an IT vulnerability monitoring tool operated to monitor an IT network to which the medical device is connected; implementing a remediation process for the vulnerability alert originating from the monitoring tool; repeating the identification and implementation to accumulate statistics on vulnerability alerts originating from the monitoring tool; and outputting an indication if the statistics indicate that the vulnerability alerts originating from the monitoring tool are placing an unacceptable burden on the service processing system.

[0015] On the other hand, a service processing system includes: a client interface via which service requests related to medical devices are received from a client; a service IT system configured to dispatch the service requests to service personnel and track the resolution status of the service requests; and an electronic processor programmed to perform a method for monitoring service requests related to IT vulnerability alerts, the method comprising: identifying service requests for IT vulnerability alerts as a source of a monitoring tool, wherein the service request includes a report of an IT vulnerability in the medical device received by the client interface, originating from an IT vulnerability monitoring tool, the IT vulnerability monitoring tool being operated to monitor the medical device's connection to... The IT network; based on service request resolution information retrieved from the service IT system, classifying IT vulnerability alerts from monitoring tools as true positives or false positives; calculating the burden on the service processing system caused by IT vulnerability alerts from monitoring tools classified as false positives on a per-customer basis; and performing remedial actions in response to the overload criterion being met by IT vulnerability alerts from monitoring tools received from a given customer that are classified as false positives, the remedial actions including at least: contacting the given customer regarding the IT vulnerability alerts from monitoring tools received from the given customer that are classified as false positives.

[0016] One advantage is the reduction of false positives in remediation requests sent to vendors from passive network scanners (i.e., monitoring tools).

[0017] Another advantage is that it provides a quantification of the burden on vendors caused by false positive vulnerability remediation requests.

[0018] Another advantage is that it provides warnings to customers who generate a large number of false positive remediation requests.

[0019] The given embodiments may not provide the foregoing advantages, provide one, two, more or all of the foregoing advantages, and / or may provide other advantages that will become apparent to those skilled in the art upon reading and understanding this disclosure. Attached Figure Description

[0020] This disclosure can take the form of various components and component arrangements, as well as various steps and step arrangements. The accompanying drawings are for illustrative purposes only and should not be construed as limiting the scope of this disclosure.

[0021] Figure 1 An illustrative service processing system based on this disclosure is shown schematically. Detailed Implementation

[0022] The following describes a method for mitigating the adverse effects of false positive vulnerability remediation requests submitted by passive scanners.

[0023] In the first step, when vulnerability remediation requests generated by passive scanners are received from the vendor, these requests are identified. If the vulnerability remediation request is submitted directly by the passive scanner, the passive scanner's API can be identified to determine that the request originated from the passive scanner. If the vulnerability remediation request is submitted by hospital IT staff, the request can be analyzed to detect the language indicating that it originated from a passive scanner. This is feasible because passive scanners typically use unique languages ​​(such as template languages) to report vulnerabilities or include specific information (such as MAC addresses, IP addresses, digital device identifiers, etc.) that human IT staff would not be likely to include.

[0024] Once a vulnerability remediation request is flagged as generated by a passive scanner, it is initially processed as usual. This may involve service personnel reviewing the request, or automated remediation algorithms may be applied. When each vulnerability remediation request is closed, it is categorized as a true positive (a vulnerability that actually exists) or a false positive (a vulnerability that does not actually exist is reported). Key performance indicators (KPIs) statistics are generated and continuously updated, such as the total number of false positive vulnerability remediation requests generated by passive scanners, the percentage of false positive vulnerability remediation requests generated by passive scanners, etc. This is done on a per-customer basis.

[0025] If one or more of a given customer's KPIs meet an unacceptable burden criterion (which indicates that false-positive vulnerability remediation requests from that customer's passive scanners are placing an excessive burden on the medical device vendor), then a warning should be issued to the customer regarding this effect. Additional remedies may also be taken, such as ceasing to accept vulnerability remediation requests from that customer's passive scanners, or imposing a penalty on any future vulnerability remediation requests from that customer's passive scanners that are identified as false positives.

[0026] Advantageously, the disclosed method provides a quantification of the burden on the vendor for false-positive vulnerability remediation requests issued by the customer's passive scanner. This information is preferably included in the alerts issued to the customer. This can encourage the customer to reassess whether to continue using the passive scanner, or (e.g., by preventing the passive scanner from automatically sending vulnerability remediation requests directly to the vendor) at least reconfigure the passive scanner. If a penalty is imposed, this quantification of the burden provides a basis for such penalty.

[0027] refer to Figure 1 , Figure 1 An illustrative service processing system 1 is schematically shown that monitors one or more monitored medical devices 10. By way of some non-limiting illustrative examples, the monitored medical device 10 may be a medical imaging device (e.g., a magnetic resonance imaging (MRI) scanner, a computed tomography (CT) scanner, a positron emission tomography (PET) scanner, a gamma camera for performing single-photon emission computed tomography (SPECT), an interventional radiology (IR) device, etc.), or it may be another type of medical device (e.g., an image-guided therapy (IGT) system, a mechanical ventilator, a multi-functional patient monitor, a radiotherapy device, etc.). The medical device 10 is computerized and may be connected to an electronic network.

[0028] like Figure 1As shown, medical device 10 is connected to electronic network 12 (e.g., a hospital IT network, a radiology IT network, etc.). It should be understood that electronic network 12 typically has many other medical devices connected to it, as well as potentially other types of devices. For example, electronic network 12 could be a hospital network interconnected with personal computers used by hospital staff, various types of medical devices (including illustrative medical device 10), hospital staff's mobile phones or other mobile devices, etc. As is recognized in the IT field, these diverse connected devices often present cybersecurity risks. Therefore, a third-party monitoring tool T (also referred to herein as monitoring tool T, network monitoring tool T, or similar terms) is deployed to monitor electronic network 12 to automatically detect cybersecurity risks presented by the various devices connected to network 12. For example, network monitoring tool T could be a passive scanner that detects various software running on medical devices (including illustrative medical device 10), computers, mobile devices, and / or other electronic devices, and compares the detected software with one or more vulnerability databases (not shown) (e.g., a generic vulnerability disclosure (CVE) database as a non-limiting illustrative example). In some embodiments, the monitoring tool T compares detected software running on electronic devices connected to the IT network 12 with a vulnerability database and marks any detected software that matches an entry in the vulnerability database as a cybersecurity threat.

[0029] The amount of analysis that monitoring tool T actually performs when identifying cybersecurity threats may be limited. This is typically due to the limited information about the software that monitoring tool T can detect and / or the limited information about cybersecurity vulnerabilities contained in the vulnerability database. For example, monitoring tool T can detect the version number of the detected software and check it against the version numbers of software listed in the vulnerability database. However, monitoring tool T may not be able to determine whether an instance of software running on an electronic device connected to network 12 includes specific modules, sub-version numbers, or other more granular information that would allow for the confirmation or exclusion of a cybersecurity threat. As another example, the monitoring tool may not be able to determine whether an instance of software running on an electronic device has received security updates that address and eliminate cybersecurity threats. Due to these limitations, monitoring tool T may produce a high rate of false positives, in which monitoring tool T marks detected software as presenting a cybersecurity threat that the actual installed instance of software does not actually present. It should also be noted that although Figure 1 The illustration shows a single monitoring tool T, but electronic network 12 can be monitored by two or more different monitoring tools, thereby further improving the false positive generation rate.

[0030] like Figure 1As further shown, the electronic processor 14 is hosted by the supplier of the medical device 10. The electronic processor 14 includes or is operatively connected to a non-transient storage medium 16, which stores instructions that can be read and executed by the electronic processor 14 to implement one or more processing modules. It should be noted that the medical device 10 may include multiple components: for example, a magnetic resonance (MR) imaging device may include an MR scanner (including a main magnet, gradient coils, radio frequency coils, etc.) located in a magnet chamber and an MR scanner controller including the electronic processor 14 located in a separate, adjacent control chamber. In this example, the medical device 10 is considered to include both an MR scanner and an MR scanner controller. As another example, the medical device 10 may be an image-guided therapy (IGT) system, which includes a medical imaging device and hardware for performing intravascular procedures or other medical procedures under the guidance of the medical imaging device.

[0031] The hospital (or other customer utilizing medical device 10 and network 12) sends a service request 11 to an electronic processor 14 hosted by the supplier of medical device 10, reporting known or suspected problems with medical device 10. Service request 11 can be generated in various ways. For example, it can be manually generated by hospital personnel and / or automatically generated by monitoring tool T. Service request 11 typically concerns observed operational problems with medical device 10, such as poor image quality in medical imaging equipment, connectivity issues with patient monitors, leaks in mechanical ventilators, etc. However, some service requests 11 may be reporting suspected cybersecurity issues. These service requests can be manually generated based on reports of cybersecurity issues from monitoring tool T, or in some configurations, can be automatically generated by monitoring tool T itself (illustratively indicated by the dashed arrow from monitoring tool T to service request 11). In the former case, the manual service request submitter can typically copy and paste the text describing the cybersecurity threat generated by monitoring tool T into the manually generated service request.

[0032] like Figure 1 As shown, service request 11 is transmitted or uploaded to the client interface 18 of the supplier's electronic processor 14. Service request 11 may be received at the client interface 18 via the Internet (in embodiments where the client interface 18 includes a website or API), or it may be a telephone or text message service request, etc. It should be noted that Figure 1 The Internet, telephone connection, or other means through which service request 11 is received are not shown. Service information technology (IT) system 20 is configured to dispatch service request 11 to service personnel and track the resolution status of service request 11.

[0033] Electronic processor 14 is programmed to execute a method for monitoring service requests 11 related to IT vulnerability alerts using modules implemented by electronic processor 14 and stored in non-transient storage medium 16. For this purpose, identification module 50 is configured to identify service requests 11 as sources of IT vulnerability alerts from monitoring tools. Each service request 11 includes a report of an IT vulnerability in medical device 10, received by client interface 18 and originating from IT vulnerability monitoring tool T, which operates to monitor the electronic IT network 12 to which medical device 10 is connected. In one embodiment, identification module 50 is programmed to identify service requests 11 as IT vulnerability alerts from monitoring tools that are received directly from monitoring tool T based on a detected application programming interface (API) 24 of monitoring tool T. Monitoring tool T is implemented in identification module 50, and the API 24 of monitoring tool T communicates with client interface 18 to receive service requests 11. In other words, monitoring tool-sourced IT vulnerability alerts generated for medical device 11 are directly generated from user input provided by employees at the medical institution where the medical device is located.

[0034] In another embodiment, the identification module 50 is programmed to identify service request 11 as an IT vulnerability alert originating from a monitoring tool based on analysis of the text of service request 11 (e.g., matching of characteristic keywords). In other words, the IT vulnerability alert originating from the monitoring tool generated for medical device 11 is directly generated by medical device 10.

[0035] The classifier module 52 is programmed to classify IT vulnerability alerts from monitoring tools as true positives or false positives based on service request resolution information retrieved from the service IT system 20. Specifically, the classifier module 52 is programmed to: identify an IT vulnerability alert from monitoring tools as a false positive if service request 11 is closed without remedial action (i.e., a service action to remediate the alert); and identify an IT vulnerability alert from monitoring tools as a true positive if service request 11 is closed after a service action to remediate the alert is taken.

[0036] The calculator module 54 is programmed to calculate the burden on the service processing system 1 caused by IT vulnerability alerts from monitoring tools. For example, this burden is calculated on a per-customer basis, based on the number or ratio of IT vulnerability alerts from monitoring tools received from the respective customers that are classified as false positives and / or the proportion of IT vulnerability alerts from monitoring tools received from the respective customers that are classified as false positives.

[0037] To calculate the workload, calculator module 54 is programmed to implement remediation processes for vulnerability alerts originating from monitoring tools. The process of identifying service request 11 as an IT vulnerability alert originating from monitoring tools and remediation processes is repeated to accumulate statistics on vulnerability alerts originating from monitoring tools. In one example, the remediation process may include receiving input from service personnel indicating a review of IT vulnerability alerts originating from monitoring tools. In another example, the remediation process may include applying an automated remediation process to implement IT vulnerability alerts originating from monitoring tools.

[0038] In some embodiments, the calculator module 54 is programmed to determine whether a vulnerability alert originating from a monitoring tool meets a predetermined false positive criterion. This determination is repeated along with identifying service request 11 as an IT vulnerability alert originating from the monitoring tool and the remediation process to further accumulate statistics on vulnerability alerts originating from the monitoring tool. To perform this determination, the calculator module 54 is programmed to generate key performance indicator (KPI) statistics indicating the likelihood that an IT vulnerability alert originating from the monitoring tool meets the predetermined false positive criterion. For example, the calculator module 54 is programmed to generate the total number of false positive IT vulnerability alerts originating from the monitoring tool. In another example, the calculator module 54 is programmed to generate the ratio of IT vulnerability alerts originating from the monitoring tool to the total number of IT vulnerability alerts originating from the monitoring tool. The calculator module 54 is programmed to determine whether the KPI exceeds the predetermined false positive criterion.

[0039] Remediation module 56 is programmed to perform remediation actions in response to an overload criterion being met by IT vulnerability alerts from monitoring tools received from a given customer that impose an excessive burden on the service processing system. As used herein, the term "remediation action" refers to an action that mitigates unnecessarily high-load service requests. In some examples, the remediation action includes at least contacting the given customer regarding IT vulnerability alerts from monitoring tools that are classified as false positives. In another example, the remediation action also includes charging for IT vulnerability alerts from monitoring tools received from the given customer. In yet another example, the remediation action also includes ceasing acceptance of IT vulnerability alerts from monitoring tools received from the given customer.

[0040] In some embodiments, the calculator module 54 is programmed to track the number of service requests identified as false positives, and the remediation module 56 is programmed to generate the root cause of the false positives. Here, the root cause is the underlying reason for the false positives (because as false positives, there is no actual cybersecurity vulnerability to be remedied). For example, consider a scenario where multiple service requests are received indicating that the operating system (OS) of a medical device presents a cybersecurity vulnerability; however, for the first one or a few such service requests, these service requests are determined to be false positives because they assume the existence of a defective component in the OS that introduces the cybersecurity vulnerability, but this defective OS component is not actually installed on the medical device. (As a specific example, the defective OS component might be a wireless communication component typically included in a commercial OS but not installed on a medical device.) In this example, the root cause is the report that the installed OS presents a cybersecurity vulnerability against the medical device, without determining whether the OS installed on the medical device actually includes this defective OS component. In one approach, these initial service requests with the same root cause are collected, and appropriate prepared responses are generated for these false positives associated with this root cause. Subsequently, future service requests related to the OS can be triaged by automatically checking for defective OS components installed on the medical device. If no defective OS component is installed, a ready response is immediately sent to the client, and the service request is closed. This directly improves the efficiency of the service processing system by removing these service requests from the service queue. Optionally, a ready message (or a variation thereof) can also be sent to the maintainer of a third-party monitoring tool T, requesting an update to tool T to check for the actual installation of defective OS components before flagging suspected cybersecurity vulnerabilities, thereby preventing tool T from issuing these false positive service requests in the future.

[0041] Output module 58 is programmed to output indications 26 related to burden and / or remedial actions. For example, output module 58 is programmed to output an indication or warning 26 if statistical data indicates that a vulnerability alert from a monitoring tool is placing an unacceptable burden on service processing system 1. Output module 58 communicates the indication or warning 26 to the user of medical device 10 via display device 28, which presents a graphical user interface (GUI) 30 on which the indication or warning 26 is displayed.

[0042] As a non-limiting illustrative example, depending on who the target customer contact is, the display device 28 can be the contact's work computer, mobile phone, or other device on which the contact reads his or her emails, text messages, or other communications. The notification 26 can be sent using communication channels (e.g., email) or intermediaries (e.g., medical device 10 or a portal used by the target customer contact). In another example, the display device 28 can be an electronic controller of the medical device 10 itself, and an instruction or warning 26 is displayed to the target customer contact when the target customer contact logs into the medical device 10.

[0043] Example Automated alerts from passive network scanners (i.e., monitoring tools) are often accompanied by false positives or incomplete or incorrect information, which can place a significant burden on medical device suppliers if customers share alerts without further screening. Therefore, these monitoring tools operate flexibly, pushing costs down the value chain through healthcare service organizations to medical device manufacturers (i.e., suppliers).

[0044] Service processing system 1 overcomes this shortcoming by recognizing such situations and by avoiding or compensating for negative consequences. For example, it charges for service requests originating from automated tools or lowers their processing priority.

[0045] Service processing system 1 is configured to: 1) identify the source of service calls (i.e., customer complaints or inquiries, especially if the source is a third-party automated monitoring tool), 2) track the KPIs of the identified tool and customer (e.g., accumulated workload or false positive rate), and 3) use tool usage and KPIs as input for subsequent actions (e.g., prioritizing service requests, charging customers, or communicating with customers).

[0046] The identification module 50 is programmed to identify whether the source of a customer service call / inquiry / complaint is an automated tool. The identification module 50 is programmed to attempt to identify the tool (e.g., a third-party security solution, also referred to herein as a network monitoring tool, or simply a monitoring tool). Implementations may be based on, for example, determining whether one or more specific tools have been used via a dedicated API, checking whether service personnel have logged customer tool usage, or machine learning to identify the tool based on service case data and descriptions. This will leverage common structures and patterns in the tool outputs appearing in the case data.

[0047] Classifier module 52 is programmed to track the correctness of alerts, which can be performed manually, automatically, or assistedly. In a manual embodiment, classifier module 52 is programmed to track the correctness of alerts as part of customer service requests (handled by service personnel and business unit SMEs). For example, whether action is needed, or whether the alert is valuable. In an automated embodiment, classifier module 52 is programmed to track the correctness of alerts by relating them to device data collected by its own supplier (via structured device connection or manual extraction), to service actions that are not present in subsequent service records, etc. The data collected by the supplier may include device logs and configurations containing identifiers (e.g., device serial number or MAC address), security-related data (e.g., software version, installed patches, security risk analysis). In an assisted embodiment, classifier module 52 is programmed to track the correctness of alerts through a combination of automated and manual embodiments.

[0048] Calculator module 54 is programmed to calculate and update KPI metrics. To this end, calculator module 54 is programmed to calculate tool quality / reputation and determine KPI metrics such as false positive rate, true positive rate, etc. KPI metrics indicate the quality of the third-party monitoring tool. Therefore, requests originating from the third-party monitoring tool and their accuracy are counted, and statistics are calculated. Additionally, specific discounts can be applied to requests with incorrect or incomplete information (e.g., incorrect device identification) that result in unnecessary time expenditure. Calculator module 54 is programmed to calculate and update KPI metrics to quantify and calculate unnecessary burdens imposed on the supplier by the customer, such as monthly per-device credit accumulation under the contract, deducting false alarms from the credit limit, adding true positives to the credit limit, etc. This enables customers to use the third-party monitoring tool in a manner suitable for their service plan (e.g., carefully screening alarms before initiating a service call under a standard service plan), or enables customers to obtain service plans that allow for a larger budget to handle service calls originating from the third-party monitoring tool. The calculator module 54 is programmed to inform customers of tool performance and (secondary) effects, an overview of alerts generated by (one or more) monitoring tools running on the customer's IT network that have been consumed over a past period, appropriate categorization (e.g., correct alerts versus false alerts), remaining budget, the impact of budget exhaustion (for both the customer and the medical device vendor), and options for when the budget for these types of alerts is exhausted (stop, pay service fees, maintain a low rate), etc.

[0049] In a specific example, a hospital with medical equipment introduced a network vulnerability monitoring tool. This tool passively observes one or more hospital networks to detect devices on the network and attempts to identify these devices (e.g., brand, type, model, (software) version).

[0050] Service processing system 1 then uses its algorithms and database to identify vulnerabilities and risks. Vulnerability data may originate from medical device manufacturer security bulletins, CVE databases, etc., and is related to the medical device as a whole or its software components (e.g., the Windows operating system). Alerts are created based on the identified vulnerabilities and risks and shared with the hospital (e.g., hospital IT or security officials).

[0051] Upon receiving the alert, the hospital contacted the manufacturer of the affected medical device. The hospital created a case (i.e., a service request) in the manufacturer's online service portal and copied and pasted an alert exported from the monitoring tool.

[0052] The manufacturer's service IT system processes incoming service requests. A third-party tool detector component attempts to identify the source of the alert. The third-party tool detector component is highly likely to determine that the alert originates from a third-party security (i.e., monitoring) tool. Artificial intelligence powering the third-party tool detector triggers the inclusion of the third-party monitoring tool name mentioned in the message and the structure of the alert included in the message. This structure may belong to a specific tool or follow common patterns common to these types of tools, such as identifiers like: MAC address, IP address, device identifier, software version, and CVE identifier supplemented with a text field. In an alternative embodiment, the detector also identifies the number of alerts referenced in the service case. Together, these elements result in the following outputs of this step: the source identified as an automated tool, the name of the third-party monitoring tool, and the number of alerts.

[0053] The output of the previous steps, combined with KPI metrics from earlier service cases, determined the subsequent processing of the service request. In the case where the hospital had no previous cases originating from automated tools and only one alert, the service request was taken into consideration.

[0054] Service personnel identify medical systems and analyze alerts. For example, they might discover an operating system vulnerability from an alert that cannot be exploited due to the design of the medical device, as the affected functionality is not enabled. Therefore, the alert is a false positive, and it is logged by the service IT system to track (incorrect) correctness (in this case, manually, similar to step 2 in the method).

[0055] The service IT system then updates the KPI metrics. The service IT system adds the number of alerts from identified third-party monitoring tools and the number of false positives. The service IT system updates the relevant ratios to the KPI metrics. The service IT system also sets the number of service requests generated by the third-party monitoring tools and the number of false positives from said third-party monitoring tools to one.

[0056] In the final step, the customer is notified. A message is delivered to the customer via the service IT system. This message answers questions about the alerts, in this case, that the system is not vulnerable to attack and the alerts are false positives. The message also includes information regarding service requests from automated third-party monitoring tools, as well as references to the aforementioned false positives and service plans.

[0057] In subsequent scenarios, the hospital has fully deployed the network vulnerability monitoring tool from the first embodiment. This time, the hospital created a system where all alerts affected service requests from medical devices originating from the manufacturer.

[0058] The service IT system again identified the source as an automated third-party monitoring tool, determining the name of the third-party monitoring tool and the number of alerts generated by it.

[0059] The output of the previous steps, combined with KPI metrics from earlier service cases, determines the subsequent processing of the service request. For previous cases originating from automated tools, where there are a significant number of alerts and no positive budget or applicable service plan, the service request will be disregarded and rejected. In this embodiment, the correctness of alert tracking is not applied and is skipped.

[0060] The service IT system uses the number of alerts for requests and rejections mentioned above to update KPI metrics. The service IT system also notifies customers that their service requests cannot be considered in conjunction with appropriate fact-based evidence (calculated using the collected KPI metrics) and applicable contextual information regarding service planning tools and options.

[0061] Non-transient storage media include any medium used to store or transfer information in a machine-readable (e.g., computer-readable) form. For example, machine-readable media include read-only memory (“ROM”), solid-state drives (SSDs), flash memory or other electronic storage media; hard disk drives, RAID arrays or other disk storage media; optical discs or other optical storage media, etc.

[0062] The methods illustrated throughout the specification can be implemented as instructions stored on a non-transient storage medium and read and executed by a computer or other electronic processor.

[0063] This disclosure has been described with reference to preferred embodiments. Others may make modifications and variations upon reading and understanding the foregoing detailed description. It is intended that the exemplary embodiments be interpreted to include all such modifications and variations, provided they fall within the scope of the appended claims or their equivalents.

Claims

1. A service processing system (1), comprising: The client interface (12) receives service requests (11) related to the medical device (10) from the client via the client interface. A service information technology (IT) system (20) configured to dispatch the service request to service personnel and track the resolution status of the service request; and An electronic processor (14) is programmed to execute a method (100) for monitoring service requests related to IT vulnerability alerts, the method comprising: Identify service requests for IT vulnerability alerts as a source of a monitoring tool, wherein the service request includes reports of IT vulnerabilities in a medical device received by the client interface from an IT vulnerability monitoring tool that operates to monitor the IT network to which the medical device is connected; Calculate the burden on the service processing system caused by IT vulnerability alerts from the monitoring tool; and Remedial action is performed in response to an IT vulnerability alert received from a given customer, originating from the monitoring tool, causing the service processing system to experience an overload criterion.

2. The service processing system (1) according to claim 1, wherein, The service request (11) for identifying IT vulnerability alerts as a source of monitoring tools includes: The application programming interface (API) (24) based on the detected monitoring tool (T) identifies the service request as an IT vulnerability alert from the monitoring tool source, received directly from the monitoring tool.

3. The service processing system (1) according to claim 1, wherein, IT vulnerability alerts that identify service requests (11) as sources of monitoring tools include: Based on the analysis of the text of the service request, the service request is identified as an IT vulnerability alert originating from a monitoring tool.

4. The service processing system (1) according to claim 1, wherein, The method (100) further includes: Based on service request resolution information retrieved from the service IT system, IT vulnerability alerts from the corresponding monitoring tools are classified as true positives or false positives.

5. The service processing system (1) according to claim 4, wherein, Classifying IT vulnerability alerts from the corresponding monitoring tools as true positives or false positives includes: If the service request (1) is closed without taking a remedial service action, the IT vulnerability alert from the monitoring tool is identified as a false positive, and if the service request is closed after taking a remedial service action, the IT vulnerability alert from the monitoring tool is identified as a true positive.

6. The service processing system (1) according to any one of claims 4 and 5, wherein, The remedial action includes at least: contacting the given customer regarding an IT vulnerability alert received from the monitoring tool that is classified as a false positive.

7. The service processing system (1) according to any one of claims 4-6, wherein, The burden is calculated on a per-customer basis, based on the number or ratio of IT vulnerability alerts received from the respective customer that are classified as false positives from monitoring tool sources and / or the proportion of IT vulnerability alerts received from the respective customer that are classified as false positives from monitoring tool sources.

8. The service processing system (1) according to any one of claims 1-7, wherein, The remedial action also includes charging for IT vulnerability alerts received from the monitoring tool source from the given customer.

9. The service processing system (1) according to claim 1, wherein, The remedial action also includes stopping the acceptance of IT vulnerability alerts from monitoring tools received from the given customer.

10. The service processing system (1) according to claim 1, wherein: The calculation of the burden on the service processing system caused by IT vulnerability alerts from the monitoring tool includes tracking the number of service requests identified as false positives. and Identify one or more service requests that are identified as false positives and have a common root cause for the false positives; The remedial actions include: preparing a response and sending it to the service request that was identified as a false positive and has the common root cause, and removing the service request that was identified as a false positive and has the common root cause from the service queue.

11. A non-transient computer-readable medium (16) storing instructions that can be read and executed by at least one electronic processor (14) to perform a method for reducing the burden of false positive information technology (IT) vulnerability alerts on a service processing system (1), the method comprising: The service request (11) received by the service processing system is identified as an IT vulnerability alert from a monitoring tool for the medical device (10), which is generated by an IT vulnerability monitoring tool that operates to monitor the IT network to which the medical device is connected. Implement remediation procedures for vulnerability alerts originating from the aforementioned monitoring tools; Repeat the identification and implementation described above to accumulate statistics on vulnerability alerts from the sources of monitoring tools; as well as If the statistics indicate that vulnerability alerts from the monitoring tool are placing an unacceptable burden on the service processing system, then an indication (26) is output.

12. The non-transient computer-readable medium (16) according to claim 11, wherein, The IT vulnerability alerts generated by the monitoring tool for the medical device (10) are generated directly by the medical device.

13. The non-transient computer-readable medium (16) according to any one of claims 11 and 12, wherein, The implementation also includes: Receive input from service personnel, which instructs them to review IT vulnerability alerts originating from the monitoring tool.

14. The non-transient computer-readable medium (16) according to any one of claims 11 and 12, wherein, The implementation also includes: An automated remediation process is applied to implement the remediation process in response to IT vulnerability alerts originating from the monitoring tool.

15. The non-transient computer-readable medium (16) according to any one of claims 11-14, wherein, The method further includes: Determine whether the vulnerability alerts from the monitoring tool meet the predetermined false positive criteria; Repeat the identification, implementation, and determination to accumulate statistics on vulnerability alerts from monitoring tool sources that meet the predetermined false positive criteria; and If the statistical data indicates that a vulnerability alert from the monitoring tool source that meets the predetermined false positive criteria is placing an unacceptable burden on the service processing system, then an indication (26) is output.

Images