Medical internet-of-things equipment security identification method

Abstract

The invention provides a medical internet-of-things equipment security identification method, which comprises the following steps of S1, establishing a unified knowledge graph based on medical equipment UDI by binding equipment hardware fingerprints and software fingerprints, and realizing cross validation from a physical layer to an application layer; the hardware fingerprint comprises an MAC address, a serial number and a sensor type; the software fingerprint comprises an operating system, an open port and a protocol feature; s2, performing medical network behavior analysis, extracting three types of metadata from mirror image traffic, dynamically updating an equipment behavior knowledge graph, and performing graded alarm according to clinical influence when a baseline is deviated; and S3, according to an analysis result, differentiated treatment of first aid / common equipment is distinguished, manual confirmation and automatic response are combined, and closed-loop feedback is performed to a knowledge graph iteration strategy.

Description

Technical Field

[0001] This invention is designed for the field of medical Internet of Things (IoT), and in particular, provides a method for secure identification of medical IoT devices. Background Technology

[0002] With the rapid proliferation of Internet of Things (IoMT) devices in healthcare, the number of medical devices in hospital networks has surged, including monitors, ventilators, and medical imaging equipment. These devices are interconnected with hospital information systems (such as PACS and HIS) via wired or wireless networks. However, the security protection of medical devices faces severe challenges: High device heterogeneity: Devices from different manufacturers use various communication protocols (such as DICOM, HL7, and MQTT), and some older devices lack security hardening, making them vulnerable to cyberattacks. Clinical sensitivity: Attacks on life support equipment (such as ECMO and anesthesia machines) can directly impact patient safety, and traditional security measures are difficult to implement without interfering with medical operations. Expanded attack surface: The access of wireless monitors and remote diagnostic devices to hospital networks increases the risk of malicious intrusion and data breaches. In recent years, ransomware attacks on medical devices have been frequent, threatening patient privacy and hospital operations. Existing network security solutions (such as firewalls and intrusion detection systems) are typically designed for general IT equipment and are ill-suited to the specific needs of medical scenarios: Lack of deep medical protocol analysis: Abnormal behavior of medical-specific protocols such as DICOM / HL7 cannot be identified. Neglecting clinical business continuity: Emergency medical devices require a "zero-interference" protection strategy, while traditional solutions may mistakenly block critical communications. Static protection models cannot dynamically adapt to the diverse fingerprint characteristics (hardware + software) and behavioral baselines of medical devices. Therefore, there is an urgent need for a multimodal security protection solution for the Internet of Things in healthcare, which can ensure trusted device identification while achieving accurate threat detection and clinically friendly security response, balancing security and medical business continuity. Summary of the Invention

[0003] To address the aforementioned technical problems, this invention proposes a secure identification method for medical IoT devices, characterized by the following steps:

[0004] Step S1: By binding the device's hardware fingerprint and software fingerprint, a unified knowledge graph is constructed based on the medical device's UDI to achieve cross-verification from the physical layer to the application layer; the hardware fingerprint includes MAC address, serial number, and sensor type; the software fingerprint includes operating system, open ports, and protocol characteristics.

[0005] Step S2: Medical network behavior analysis, extracting three types of metadata from mirrored traffic, dynamically updating the device behavior knowledge graph, and issuing alarms based on clinical impact when deviating from the baseline;

[0006] Step S3: Based on the analysis results, differentiate between emergency and general equipment treatment, combine manual confirmation with automatic response, and feed the closed-loop feedback to the knowledge graph iteration strategy.

[0007] Furthermore, step S1 further includes:

[0008] Step S11: Hardware fingerprint acquisition.

[0009] Step S12: Software fingerprint collection.

[0010] Step S13: Perform fusion processing on the above hardware fingerprint and software fingerprint;

[0011] Step S14: Register the knowledge graph of software and hardware fingerprints and process abnormal information;

[0012] Step S15: Dynamically iterate the risk assessment and modify the weights of the software and hardware fingerprints.

[0013] Furthermore, the hardware fingerprint acquisition in step S11 includes:

[0014] Step S111. Physical layer feature extraction

[0015] The serial number and FDA UDI are read through the device interface (RS-232 / USB) to obtain the MAC address and Bluetooth characteristics of the wireless device using non-invasive radio frequency scanning, and sensor type and accuracy parameters (such as ECG sampling rate ±5% tolerance) are collected.

[0016] Step S112. Medical environment adaptation: Intermittent acquisition (treatment interval) is adopted for ICU equipment, and low-power BLE sniffing mode is enabled for implantable devices.

[0017] Furthermore, the software fingerprint acquisition in step S12 includes:

[0018] Step S121. Perform protocol stack depth analysis.

[0019] Identify the protocol characteristics of DICOM (port 104) / HL7 (port 2100) in mirrored traffic, extract medical-specific fields such as AE Title and message type, and decrypt TLS traffic to obtain cipher suite characteristics (such as GE equipment-specific encryption configuration);

[0020] S122. Perform runtime environment detection, identify the embedded OS (such as VxWorks / QNX) through TCP / IP stack fingerprinting, and compare the open ports with the medical device benchmark library (normal infusion pumps should have 3003 / TCP open).

[0021] Step S13, fusing the hardware fingerprint and software fingerprint, includes:

[0022] S131. Perform multimodal association by matching the hardware serial number with the device declaration in the software protocol to establish a three-dimensional mapping relationship;

[0023] S132. Perform dynamic consistency verification, including:

[0024] Positive verification: Check if the ventilator firmware version is on the manufacturer's whitelist;

[0025] Reverse verification: Confirms that the PACS server should not have the hardware features of an infusion pump;

[0026] Threshold control: Allows ±2% clock drift (for compatible device aging).

[0027] Furthermore, step S14, registering the knowledge graph of software and hardware fingerprints and processing abnormal information, includes:

[0028] Step S141: Legitimate device processing. The fields stored in the medical asset knowledge graph include: hardware fingerprint (SN / MAC / sensor hash value), software fingerprint (protocol fingerprint + vulnerability score), and clinical metadata (ward / criticality level).

[0029] Step S142, the exception handling procedure, is as follows:

[0030] Primary alert: Indicates a minor hardware and software mismatch and is marked as pending review;

[0031] Advanced alert: Indicates a critical feature conflict, allowing for immediate isolation;

[0032] Clinical review: This indicates that the emergency equipment is malfunctioning and requires secondary confirmation at the nursing station.

[0033] Furthermore, step S15, dynamically performing risk assessment iterations and modifying the weights of the software and hardware fingerprints, includes:

[0034] S151, Dynamic weight adjustment, assigning different risk coefficients based on equipment type;

[0035] S152, The relevant database is corrected based on the feedback learning mechanism.

[0036] Furthermore, step S2, medical network behavior analysis, extracts three types of metadata from mirrored traffic, dynamically updates the device behavior knowledge graph, and issues alarms based on clinical impact levels when deviations from the baseline. Specifically, this includes:

[0037] Step S21, medical traffic collection and preprocessing, including data source deployment and configuration, as well as traffic preprocessing and filtering;

[0038] Step S22: Multi-dimensional metadata extraction and analysis;

[0039] Step S23, Knowledge Graph Construction and Update;

[0040] Step S24, graded response and handling;

[0041] Step S25: Continuous optimization and improvement.

[0042] Furthermore, step S21, medical traffic collection and preprocessing, includes data source deployment and configuration, and traffic preprocessing and filtering, including:

[0043] Step S211. Data source deployment and configuration: Deploy traffic mirroring ports on the network core switch and the aggregation switches in each medical area to ensure coverage of all medical device communication paths;

[0044] For wireless medical devices, medical-grade wireless probes are installed in critical areas such as ICUs and operating rooms, configured to monitor only designated frequency bands (e.g., 5.8GHz).

[0045] It interfaces with the hospital's existing medical systems (such as PACS and HIS) to obtain device communication logs and system alarm information;

[0046] Step S212. Flow preprocessing and filtering

[0047] Establish a whitelist database for medical devices, containing the MAC address, IP range, and device type information of all legitimate medical devices;

[0048] Configure traffic filtering rules to exclude non-medical traffic such as hospital office network and visitor network;

[0049] Metadata is extracted from encrypted traffic to record basic communication characteristics without decrypting the content, ensuring compliance with medical privacy protection requirements.

[0050] Furthermore, step S22: multi-dimensional metadata extraction and analysis specifically includes:

[0051] Step S221. Communication relationship analysis: Extract and record complete communication quintuple information (source IP, destination IP, source port, destination port, protocol type), and perform in-depth analysis for medical-specific protocols (DICOM / HL7 / IHE): Extract SCU / SCP roles, AE Titles and application scenario information from DICOM communication, parse sender / receiver application identifiers, message types and key fields from HL7 messages, and construct a complete communication relationship graph of device-system-user;

[0052] Step S222. Transmission behavior analysis: Establish differentiated analysis strategies according to device type. For vital sign monitoring devices, monitor their real-time data reporting frequency and continuity. For medical imaging devices, analyze their entire process behavior characteristics of examination-transmission-storage. For therapeutic devices (such as infusion pumps and ventilators), monitor the legality and timing characteristics of their control commands. Use sliding time window technology to dynamically calculate the communication frequency baseline of each device.

[0053] Step S223. Data packet feature analysis, including structural feature analysis and timing feature analysis, wherein: structural feature analysis includes analyzing the distribution characteristics of protocol packet lengths, identifying data packets of abnormal size, detecting the integrity and legality of protocol fields, and identifying malformed messages; timing feature analysis includes: calculating the statistical characteristics of the data packet arrival time interval, establishing a timing model of the communication session, and detecting timing anomalies.

[0054] Furthermore, step S23, knowledge graph construction and updating, includes medical network entity modeling and anomaly detection and risk assessment, wherein...

[0055] Step S231. Medical network entity modeling: Define multiple types of entities including medical devices, network devices, information systems, and users; establish a multi-dimensional relationship model between devices, networks, systems, and users, and attach static attributes (device type, location, etc.) and dynamic attributes (communication characteristics, risk status, etc.) to each entity;

[0056] Step S232. Anomaly detection and risk assessment, including establishing multi-level detection rules based on medical business scenarios:

[0057] Protocol compliance rules: Detect the use of non-standard or non-compliant protocols;

[0058] Abnormal behavior rules: Identify communication patterns that deviate from the baseline;

[0059] Relationship anomaly rule: Detects illegal inter-device communication;

[0060] Step S233. Conduct risk assessment and classification based on the clinical importance of the equipment.

[0061] Furthermore, step S24, graded response and handling, includes alarm grading and response strategies as well as clinical operational safeguards:

[0062] Step S241. Alarm classification and response strategy: Alarms are classified into four levels: emergency, high-risk, medium-risk, and low-risk. Each level has a clearly defined response process. Special handling procedures are set up for alarms related to emergency equipment to ensure that clinical treatment is not affected. A handling mechanism that combines automatic response and manual confirmation is established.

[0063] Step S242. Clinical business support measures: Develop an emergency communication support plan for network isolation, reserve necessary network bandwidth for critical medical equipment, and establish a rapid response channel for clinical engineers.

[0064] This solution provides a protection system for Internet of Things (IoMT) devices that balances security and clinical applicability through multimodal fusion recognition, medical business perception analysis, and a hierarchical response mechanism, offering the following significant benefits:

[0065] Multi-dimensional cross-verification enhances device identity credibility: By fusing hardware fingerprints (serial number / MAC) and software fingerprints (protocol / port), the false alarm rate for device forgery is reduced to <0.8% (compared to approximately 5% for traditional solutions). Deep medical protocol analysis: Accurately identifies abnormal fields in protocols such as DICOM / HL7 (e.g., illegal AE Titles), achieving a 3-fold increase in the detection rate of medical-specific attacks. Ensuring clinical business continuity with "zero-interference" protection for emergency equipment: Employing an alarm-only, non-interruption strategy for devices such as ventilators and ECMO machines ensures 100% uninterrupted transmission of vital signs. Attached Figure Description

[0066] Figure 1 Multimodal fingerprint fusion recognition process;

[0067] Figure 2 Medical network behavior analysis process;

[0068] Figure 3 : Safety response closed-loop process. Detailed Implementation

[0069] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the protection scope of the present invention.

[0070] According to an embodiment of the present invention, a method for secure identification of medical Internet of Things (IoT) devices is proposed, comprising the following steps:

[0071] Step S1: By binding the device's hardware fingerprint and software fingerprint, a unified knowledge graph is constructed based on the medical device's UDI to achieve cross-verification from the physical layer to the application layer; the hardware fingerprint includes MAC address, serial number, and sensor type; the software fingerprint includes operating system, open ports, and protocol characteristics.

[0072] Step S2: Medical network behavior analysis, extracting three types of metadata from mirrored traffic, dynamically updating the device behavior knowledge graph, and issuing alarms based on clinical impact when deviating from the baseline;

[0073] Step S3: Based on the analysis results, differentiate between emergency and general equipment treatment, combine manual confirmation with automatic response, and feed the closed-loop feedback to the knowledge graph iteration strategy.

[0074] Furthermore, step S1 further includes:

[0075] Step S11: Hardware fingerprint acquisition.

[0076] Step S12: Software fingerprint collection.

[0077] Step S13: Perform fusion processing on the above hardware fingerprint and software fingerprint;

[0078] Step S14: Register the knowledge graph of software and hardware fingerprints and process abnormal information;

[0079] Step S15: Dynamically iterate the risk assessment and modify the weights of the software and hardware fingerprints.

[0080] Furthermore, the hardware fingerprint acquisition in step S11 includes:

[0081] S111. Physical Layer Feature Extraction

[0082] The serial number and FDA UDI are read through the device interface (RS-232 / USB) to obtain the MAC address and Bluetooth characteristics of the wireless device using non-invasive radio frequency scanning, and sensor type and accuracy parameters (such as ECG sampling rate ±5% tolerance) are collected.

[0083] S112. Medical environment adaptation: intermittent acquisition (during treatment intervals) is adopted for ICU equipment, and low-power BLE sniffing mode is enabled for implantable devices.

[0084] Furthermore, the software fingerprint acquisition in step S12 includes:

[0085] S121. Perform protocol stack depth analysis

[0086] Identify the protocol characteristics of DICOM (port 104) / HL7 (port 2100) in mirrored traffic, extract medical-specific fields such as AE Title and message type, and decrypt TLS traffic to obtain cipher suite characteristics (such as GE equipment-specific encryption configuration);

[0087] S122. Runtime environment detection: Identify the embedded OS (such as VxWorks / QNX) through TCP / IP stack fingerprinting and compare open ports with the medical device benchmark library (normal infusion pumps should have ports 3003 / TCP open).

[0088] Furthermore, step S13, fusing the hardware fingerprint and software fingerprint, includes:

[0089] S131. Perform multimodal association by matching the hardware serial number with the device declaration in the software protocol to establish a three-dimensional mapping relationship;

[0090] The specific mapping relationship is as follows:

[0091] S132. Perform dynamic consistency verification, including:

[0092] Positive verification: Check if the ventilator firmware version is on the manufacturer's whitelist;

[0093] Reverse verification: Confirms that the PACS server should not have the hardware features of an infusion pump;

[0094] Threshold control: Allows ±2% clock drift (for compatible device aging).

[0095] Further, step S14 involves registering the knowledge graph of software and hardware fingerprints and processing abnormal information, including:

[0096] Step S141: Legitimate device processing. The fields stored in the medical asset knowledge graph include: hardware fingerprint (SN / MAC / sensor hash value), software fingerprint (protocol fingerprint + vulnerability score), and clinical metadata (ward / criticality level).

[0097] Step S142, the exception handling procedure, is as follows:

[0098] Primary alert: Indicates a minor hardware and software mismatch and is marked as pending review;

[0099] Advanced alert: Indicates a critical feature conflict, allowing for immediate isolation;

[0100] Clinical review: This indicates that the emergency equipment is malfunctioning and requires secondary confirmation at the nursing station.

[0101] Furthermore, in step S15, the risk assessment is dynamically iterated, and the weights of the software and hardware fingerprints are modified, including:

[0102] S151, Dynamic weight adjustment, assigning different risk coefficients based on equipment type;

[0103] S152, The relevant database is corrected based on the feedback learning mechanism.

[0104] For example, for an external defibrillator, the hardware weight is 70% and the software weight is 30%; for an electronic medical record terminal, the hardware weight is 30% and the software weight is 70%.

[0105] 2. Feedback Learning Mechanism

[0106] For example, the recognition algorithm is corrected monthly by manual verification results, and new devices automatically trigger the expansion of the fingerprint database for dynamic feedback and correction.

[0107] Furthermore, step S2, medical network behavior analysis, extracts three types of metadata from mirrored traffic, dynamically updates the device behavior knowledge graph, and issues alarms based on clinical impact levels when deviations from the baseline. Specifically, this includes:

[0108] Step S21, medical traffic collection and preprocessing, including data source deployment and configuration, as well as traffic preprocessing and filtering;

[0109] Step S22: Multi-dimensional metadata extraction and analysis;

[0110] Step S23, Knowledge Graph Construction and Update;

[0111] Step S24, graded response and handling;

[0112] Step S25: Continuous optimization and improvement.

[0113] Further, step S21, medical traffic collection and preprocessing, includes data source deployment and configuration, as well as traffic preprocessing and filtering, including:

[0114] Step S211. Data source deployment and configuration: Deploy traffic mirroring ports on the network core switch and the aggregation switches in each medical area to ensure coverage of all medical device communication paths;

[0115] For wireless medical devices, medical-specific wireless probes are installed in key areas such as ICUs and operating rooms, and configured to monitor only designated frequency bands (such as 5.8GHz);

[0116] It interfaces with the hospital's existing medical systems (such as PACS and HIS) to obtain device communication logs and system alarm information;

[0117] Step S212. Flow preprocessing and filtering:

[0118] Establish a whitelist database for medical devices, containing the MAC address, IP range, and device type information of all legitimate medical devices;

[0119] Configure traffic filtering rules to exclude non-medical traffic such as hospital office network and visitor network;

[0120] Metadata is extracted from encrypted traffic to record basic communication characteristics without decrypting the content, ensuring compliance with medical privacy protection requirements.

[0121] Further, step S22: multi-dimensional metadata extraction and analysis, specifically includes:

[0122] Step S221. Communication relationship analysis: Extract and record complete communication quintuple information (source IP, destination IP, source port, destination port, protocol type), and perform in-depth analysis for medical-specific protocols (DICOM / HL7 / IHE): Extract SCU / SCP roles, AE Titles and application scenario information from DICOM communication, parse sender / receiver application identifiers, message types and key fields from HL7 messages, and construct a complete communication relationship graph of device-system-user;

[0123] Step S222. Transmission behavior analysis: Establish differentiated analysis strategies according to device type. For vital sign monitoring devices, monitor their real-time data reporting frequency and continuity. For medical imaging devices, analyze their entire process behavior characteristics of examination-transmission-storage. For therapeutic devices (such as infusion pumps and ventilators), monitor the legality and timing characteristics of their control commands. Use sliding time window technology to dynamically calculate the communication frequency baseline of each device.

[0124] Step S223. Data packet feature analysis, including structural feature analysis and timing feature analysis, wherein: structural feature analysis includes analyzing the distribution characteristics of protocol packet lengths, identifying data packets of abnormal size, detecting the integrity and legality of protocol fields, and identifying malformed messages; timing feature analysis includes: calculating the statistical characteristics of the data packet arrival time interval, establishing a timing model of the communication session, and detecting timing anomalies.

[0125] Further, step S23, knowledge graph construction and updating, includes medical network entity modeling and anomaly detection and risk assessment, among which...

[0126] Step S231. Medical network entity modeling: Define multiple types of entities including medical devices, network devices, information systems, and users; establish a multi-dimensional relationship model between devices, networks, systems, and users, and attach static attributes (device type, location, etc.) and dynamic attributes (communication characteristics, risk status, etc.) to each entity;

[0127] Step S232. Anomaly detection and risk assessment, including establishing multi-level detection rules based on medical business scenarios:

[0128] Protocol compliance rules: Detect the use of non-standard or non-compliant protocols;

[0129] Abnormal behavior rules: Identify communication patterns that deviate from the baseline;

[0130] Relationship anomaly rule: Detects illegal inter-device communication;

[0131] Step S233. Conduct risk assessment and classification based on the clinical importance of the equipment.

[0132] Furthermore, step S24, tiered response and handling, includes alarm tiering and response strategies, as well as clinical operational safeguards:

[0133] Step S241. Alarm classification and response strategy: Alarms are classified into four levels: emergency, high-risk, medium-risk, and low-risk. Each level has a clearly defined response process. Special handling procedures are set up for alarms related to emergency equipment to ensure that clinical treatment is not affected. A handling mechanism that combines automatic response and manual confirmation is established.

[0134] Step S242. Clinical business support measures: Develop an emergency communication support plan for network isolation, reserve necessary network bandwidth for critical medical equipment, and establish a rapid response channel for clinical engineers.

[0135] Furthermore, step 5: continuous optimization and improvement includes the following:

[0136] 5.1 System Adaptive Optimization

[0137] Establish a feedback learning mechanism to continuously optimize detection rules and thresholds;

[0138] Regularly evaluate system performance metrics, including detection rate, false alarm rate, and response time;

[0139] 5.2. Optimization of Medical Business Collaboration

[0140] Communicate regularly with clinical departments to adjust strategies to adapt to changes in business operations;

[0141] The knowledge base is updated promptly in response to the introduction of new medical equipment and technologies.

[0142] Furthermore, step S3 specifically includes:

[0143] Step S31: Classification and preliminary assessment of abnormal events;

[0144] Step S32: Execute the differentiated response strategy;

[0145] Step S33: Clinical collaboration and manual confirmation;

[0146] Step S34: Dynamically update the knowledge graph;

[0147] Step S35: Closed-loop verification and continuous improvement.

[0148] Step S31: Abnormal event classification and preliminary assessment

[0149] S311. Perform event detection and classification, receive security alarms from the monitoring system, including equipment anomalies, network attacks, behavioral deviations, etc., and automatically classify them according to preset rules:

[0150] Equipment type (life support equipment / diagnostic equipment / general equipment);

[0151] Threat types (spoofed device / protocol attack / denial of service, etc.);

[0152] Scope of impact (single device / department / hospital-wide);

[0153] S312. Conduct a criticality assessment and query the device knowledge graph to obtain the clinical criticality level:

[0154] Emergency medical equipment (ECMO, ventilators, etc.);

[0155] Diagnostic equipment (CT, MRI, etc.);

[0156] Auxiliary equipment (infusion pumps, monitors, etc.);

[0157] Assess the potential impact in conjunction with the ward where the equipment is located (ICU / general ward, etc.);

[0158] Step S32: Execution of Differentiated Response Strategy

[0159] S321. Life support equipment handling procedure: Immediately notify the clinical engineering team and the department using the equipment; display alarm information (red / yellow / blue three levels) on the monitoring screen at the nurse station; maintain network connectivity; record but do not block: maintain basic vital sign data transmission and limit unnecessary communication bandwidth (such as log upload); clinical engineers confirm the handling on-site.

[0160] S322. Procedures for handling general medical equipment.

[0161] Automatically execute preset protection measures: network isolation (devices are taken offline via the NAC system), port blocking (firewall policy updates), session termination (sending TCP RST packets), and generate electronic work orders to be dispatched to the corresponding departments;

[0162] S323. Information system-related measures, for core systems such as PACS and HIS: activate backup links to ensure business continuity, restrict access from suspicious IPs, and trigger data backup processes;

[0163] Step S33: Clinical Collaboration and Manual Confirmation

[0164] S331. The multi-departmental collaboration mechanism is as follows: the connection process between the safety team and clinical departments: emergency equipment: telephone confirmation within 30 seconds, general equipment: work order response within 5 minutes; establish a green channel for clinical decision-making: allow attending physicians to temporarily authorize the release from isolation, and provide emergency communication support solutions;

[0165] S332. The false alarm handling process is as follows: Bed staff can provide feedback through multiple channels: one-click confirmation button at the nurse station; embedded work order system in the HIS system; and notification via a dedicated mobile APP.

[0166] S333 False Alarm Analysis and Rule Optimization: Record false alarm scenarios and device characteristics, summarize and analyze them weekly, and adjust the detection strategy accordingly;

[0167] Step S34: Dynamically update the knowledge graph, specifically including:

[0168] S341. Event data back-injection: Update the complete information of confirmed security events to the knowledge graph.

[0169] Attack characteristics (including IP address, fingerprint, behavioral patterns, etc.);

[0170] The handling process (including handling measures, time taken, and results);

[0171] Clinical feedback (including impact assessment, improvement suggestions, etc.)

[0172] S342. Strategy optimization iteration, adaptive adjustment of the rule base:

[0173] Prioritize the detection of verified threats;

[0174] Reduce the sensitivity of rules that frequently generate false alarms;

[0175] Added detection of derivative attack signatures;

[0176] Monthly strategy optimization reports are generated.

[0177] Step S35: Closed-loop verification and continuous improvement

[0178] 1. Evaluation of treatment effectiveness and monitoring of key indicators: including response time (from alarm to completion of treatment), business impact (equipment downtime), and clinical satisfaction (departmental feedback score);

[0179] 2. The hospital-wide security situation evolution, including the establishment of a security baseline trend map, identification of high-risk departments / equipment types, and targeted strengthening of protective measures.

[0180] Although the illustrative specific embodiments of the present invention have been described above to enable those skilled in the art to understand the invention, it should be understood that the invention is not limited to the scope of the specific embodiments. For those skilled in the art, various changes will be obvious as long as they are within the spirit and scope of the invention as defined and determined by the appended claims, and all inventions utilizing the concept of the present invention are protected.

Claims

1. A method for secure identification of medical IoT devices, characterized in that, Includes the following steps: Step S1: By binding the device's hardware fingerprint and software fingerprint, a unified knowledge graph is constructed based on the medical device's UDI to achieve cross-verification from the physical layer to the application layer; the hardware fingerprint includes MAC address, serial number, and sensor type; the software fingerprint includes operating system, open ports, and protocol characteristics. Step S2: Medical network behavior analysis, extracting three types of metadata from mirrored traffic, dynamically updating the device behavior knowledge graph, and issuing alarms based on clinical impact when deviating from the baseline; Step S3: Based on the analysis results, differentiate between emergency and general equipment treatment, combine manual confirmation with automatic response, and feed the closed-loop feedback to the knowledge graph iteration strategy.

2. The method for secure identification of medical IoT devices according to claim 1, characterized in that, Step S1 further includes: Step S11: Hardware fingerprint acquisition. Step S12: Software fingerprint collection; Step S13: Perform fusion processing on the above hardware fingerprint and software fingerprint; Step S14: Register the knowledge graph of software and hardware fingerprints and process abnormal information; Step S15: Dynamically iterate the risk assessment and modify the weights of the software and hardware fingerprints.

3. The feature described in claim 1 A method for secure identification of medical IoT devices, characterized in that the hardware fingerprint acquisition in step S11 includes: Step S111. Physical layer feature extraction: Read the serial number, FDA UDI and other unique identifiers through the device interface, use non-invasive radio frequency scanning to obtain the MAC address and Bluetooth features of the wireless device, and collect sensor type and accuracy parameters. Step S112. Medical environment adaptation: intermittent data acquisition is used for ICU equipment, and low-power BLE sniffing mode is enabled for implantable devices.

4. The feature described in claim 1 A method for secure identification of medical IoT devices, characterized in that the software fingerprint acquisition in step S12 includes: Step S121. Perform deep parsing of the protocol stack, identify the protocol characteristics of DICOM / HL7 in the mirrored traffic, extract medical-specific fields such as AETitle and message type, and decrypt TLS traffic to obtain cipher suite characteristics; Step S122. Perform runtime environment detection, identify the embedded OS through TCP / IP stack fingerprinting, and compare open ports with medical device benchmark libraries.

5. The feature described in claim 1 A method for secure identification of medical IoT devices, characterized in that step S13, fusing the hardware fingerprint and software fingerprint, includes: Step S131: Perform multimodal association by matching the hardware serial number with the device declaration in the software protocol to establish a three-dimensional mapping relationship; Step S132: Perform dynamic consistency verification, including: Positive verification: Check if the ventilator firmware version is on the manufacturer's whitelist; Reverse verification: Confirms that the PACS server should not have the hardware features of an infusion pump; Threshold control: Allows ±2% clock drift, compatible with device aging.

6. The feature of claim 1 A method for secure identification of medical IoT devices, characterized in that step S14, registering a knowledge graph of software and hardware fingerprints and processing abnormal information, includes: Step S141, legitimate device processing, the fields stored in the medical asset knowledge graph include: hardware fingerprint, software fingerprint, clinical metadata; Step S142, the exception handling procedure, is as follows: Primary alert: Indicates a minor hardware and software mismatch and is marked as pending review; Advanced alert: Indicates a critical feature conflict, allowing for immediate isolation; Clinical review: This indicates that the emergency equipment is malfunctioning and requires secondary confirmation at the nursing station.

7. The feature of claim 1 A method for secure identification of medical IoT devices, characterized in that step S2, medical network behavior analysis, extracts three types of metadata from mirrored traffic, dynamically updates the device behavior knowledge graph, and issues alarms based on clinical impact when deviations from the baseline, specifically including: Step S21, medical traffic collection and preprocessing, including data source deployment and configuration, as well as traffic preprocessing and filtering; Step S22: Multi-dimensional metadata extraction and analysis; Step S23, Knowledge Graph Construction and Update; Step S24, graded response and handling; Step S25: Continuous optimization and improvement.

8. The feature of claim 1 A method for secure identification of medical IoT devices, characterized in that step S21, medical traffic collection and preprocessing, includes data source deployment and configuration, and traffic preprocessing and filtering, including: Step S211. Data source deployment and configuration: Deploy traffic mirroring ports on the network core switch and the aggregation switches in each medical area to ensure coverage of all medical device communication paths; For wireless medical devices, medical-grade wireless probes are installed in key areas such as the ICU and operating room, configured to monitor only designated frequency bands; they are also integrated with the hospital's existing medical system to obtain device communication logs and system alarm information. Step S212. Flow preprocessing and filtering: Establish a whitelist database for medical devices, containing the MAC address, IP range, and device type information of all legitimate medical devices; Configure traffic filtering rules to exclude non-medical traffic from the hospital's office network and visitor network; Metadata is extracted from encrypted traffic to record basic communication characteristics without decrypting the content, ensuring compliance with medical privacy protection requirements.

9. The feature of claim 1 A method for secure identification of medical IoT devices, characterized in that step S22: multi-dimensional metadata extraction and analysis, specifically includes: Step S221. Communication relationship analysis: Extract and record complete communication quintuple information, and perform in-depth analysis of medical-specific protocols: Extract SCU / SCP roles, AE titles and application scenario information from DICOM communication, parse sender / receiver application identifiers, message types and key fields from HL7 messages, and construct a complete communication relationship graph of device-system-user; Step S222. Transmission behavior analysis: Establish differentiated analysis strategies according to device type. For vital sign monitoring devices, monitor their real-time data reporting frequency and continuity. For medical imaging devices, analyze their entire process behavior characteristics of examination-transmission-storage. For therapeutic devices, monitor the legality and timing characteristics of their control commands. Use sliding time window technology to dynamically calculate the communication frequency baseline of each device. Step S223. Data packet feature analysis, including structural feature analysis and timing feature analysis, wherein: structural feature analysis includes analyzing the distribution characteristics of protocol packet lengths, identifying data packets of abnormal size, detecting the integrity and legality of protocol fields, and identifying malformed messages; timing feature analysis includes: calculating the statistical characteristics of the data packet arrival time interval, establishing a timing model of the communication session, and detecting timing anomalies.

10. The feature of claim 1 A method for secure identification of medical IoT devices, characterized in that step S23, knowledge graph construction and updating, includes medical network entity modeling and anomaly detection and risk assessment, wherein... Step S231. Medical network entity modeling: Define multiple types of entities, including medical devices, network devices, information systems, and users; establish a multi-dimensional relationship model between devices, networks, systems, and users, and attach static and dynamic attributes to each entity. Step S232. Anomaly detection and risk assessment, including establishing multi-level detection rules based on medical business scenarios: Protocol compliance rules: Detect the use of non-standard or non-compliant protocols; Abnormal behavior rules: Identify communication patterns that deviate from the baseline; Relationship anomaly rule: Detects illegal inter-device communication; Step S233. Conduct risk assessment and classification based on the clinical importance of the equipment.

Images