VDGH-Whitepaper

IT-Product Security Whitepaper Template

Table of content

Download

Preface

The IT-Security of medical devices, also known as 'product security', is an important aspect of their functionality. It is essential for their safe operation and to ensure:

  • Confidentiality of patient data
  • Integrity of the medical device, i.e. the device functions as intended.
  • Availability of the medical device

To ensure product security, a medical device must be designed, implemented and tested properly. Moreover, it must be installed, configured, maintained and operated as intended. Failure to observe any of these aspects can easily compromise the product security of the medical device, with potentially severe consequences for its safety.

The intention of the IT-Product Security Whitepaper Template is to provide those responsible for the installation, maintenance and operation of medical devices with all the necessary information to carry out their work to the required standard:

  • Provide information on all relevant product security aspects to customers and service personnel.
  • Ensure the availability of all data and guidance required for the secure installation, configuration, maintenance and operation of the system.

In addition, the IT-Product Security Whitepaper Template is intended to provide all the information that may be required during the procurement and selection process for a medical device, thereby eliminating the need for customer-specific questionnaires.

To top

1. Product Security Whitepaper: Content and Intention

The following content should be considered when writing the security white paper for any medical device, whether it is a system, software only or a solution. The content must be adapted to the specific nature of the medical device in question. 

This Product Security Whitepaper describes the technical aspects of the product that are relevant for IT-Security. It is intended primarily for service and customer personnel responsible for installation, configuration, maintenance and operation, as well as for marketing and sales teams to support the procurement process. However, it should also be made available to customers upon request to promote transparency.

This Product Security Whitepaper contains all the information required to:

  • Support the procurement and selection process for medical devices
  • Avoid the need for generic security questionnaires
  • Provide this information to customers and service personnel
  • Securing installation, configuration, maintenance and operation of the medical devices
To top

2. General Information

  • Contact details (email address, website) for submitting vulnerability and incident notifications
  • ISMS/ISO 27001 & NIS-2
  • CRA
  • PSIRT/CSIRT
  • CVD process (often used as a criterion to determine an organisation's maturity level)
To top

3. Security Program

Generic (marketing) information on the security program, incident management and vulnerability management. Additionally, information on:

  • Security by design
  • Security testing
  • Secure configuration
  • Security training
  • Other security program elements implemented by the supplier
To top

4. System Information

4.1 System Overview

Brief overview of the product:

  • Description of the product, its intended use and market segment
  • Device list (e.g. analysers, PCs, network equipment) and optional components (e.g. printers, barcode readers, NAS, UPS, external firewalls, network switches).
  • Intended Use statement
  • Intended operational environment
  • Operation in virtualisation environments

4.2 Hardware Specifications

Description of the details of the hardware being shipped (even if not used) or required to operate the product (minimum specifications), including:

  • Full specifications of PCs or servers
  • Input devices (e.g. keyboards, touchpads, touchscreens, computer mice etc.)
  • Output devices (e.g. monitors, printers etc.)
  • External LAN, USB or FireWire ports
  • Handheld barcode reader
  • Uninterruptible power supply
  • Wireless communication components (e.g. Wi-Fi, Bluetooth, infrared, RFID etc.).
  • Camera, microphone, fingerprint reader
  • Compliance (CE, RoHS, FCC)

4.3 Product Software

Description of the security-related features and aspects of the product.

  • User authentication
  • Audit logging
  • Connectivity
  • Software updates and patches
  • Reports
  • Database

4.4 Operating System

Configuration of the operating system (OS) that is shipped with the product, or configuration that the customer is required to provide in order to run the product.

4.4.1 OS Version Information

  • Name and version of the operating system
  • End of support

4.4.2 Patch Level and Patch Policy

  • Patch level of the operating system at delivery
  • Vendor patch policy and interval

4.4.3 Firewall

  • Type, name and version of firewall
  • State
  • Exceptions
  • Logging
  • Default deny for incoming/outgoing connections

4.4.4 Network Configuration

  • Internet/web access restricted
  • IPv6
  • Communication encrypted (TLS-Version)
  • DHCP requirements
  • DNS requirements
  • NTP requirements
  • Wi-Fi (including encryption algorithm)

4.4.5 Hardening

  • Standard or custom
  • Unneeded accounts disabled
  • Unneeded file shares disabled
  • Unneeded ports disabled
  • Unneeded services disabled
  • Unneeded applications disabled
  • Restriction of external (USB) devices
  • Authentication of external devices (e.g. USB Type-C Authentication Specification)

4.4.6 Customer Supplied Software

  • Printer drivers
  • Customer antimalware
  • Other tools

4.5 Third Party Software

Software supplied by third party suppliers with the product or required to operate it. This may be Off-The-Shelf (OTS) or Open Source Software (OSS).

  • Type of software
  • Supplier
  • Version information
  • Licensing information
  • Vulnerability monitoring and patching
  • Configuration information
  • Configuration settings required for regular use
  • Software Bill of Materials (SBOM) availability

4.6 Connectivity

Description of how the product connects to and interacts with its environment:

  • How does the system connect to the environment?
  • IP configuration
  • LIS/LAS / remote service connectivity
    • Protocol and (default/serial) ports
    • Modes and default mode (server/client)
    • Data format (file format or application layer protocol)
    • Services running on the system
    • “Keep alive” signal ensures the device remains connected during periods of inactivity
  • For each type of connectivity (e.g. secure download, web service, SOAP, VNC, remote desktop, file sharing etc.)
    • Protocol and (default) ports (e.g. SMB/124)
    • Services running on the system
    • Service discovery
    • Data format (file format or application layer protocol)
    • Multicast

4.7 Security Patching

  • Description of patch process (for vendor- or customer-supplied patches)
  • Availability of patches
    • Components which are being patched
    • Timeframe of patching
    • Delivery channels for patches

4.8 Sensitive Data

  • Types of sensitive data that is processed by the product (e.g. demographic, diagnostic, therapeutic, financial, employee or other personally identifiable information)
  • Statement on how customer data is processed (e.g. stored on or transmitted to the vendor’s infrastructure or local storage only)
  • Methods and scenarios used to de-identify sensitive data (e.g. replacement of data by asterisks when service is logged in, in log files or in printed reports) – anonymisation and/or pseudonymisation
  • Handling of sensitive data in transit or at rest (e.g. encrypted when transmitted via network, when exported, when at rest in database)
  • Handling of sensitive data when system is decommissioned
To top

5. Network Diagram or System Diagram

5.1 Network diagram or system diagram of the product

<network diagram>

To top

6. Technical Security Controls

Short summary of all technical security controls described in this document.

6.1 Malware and Vulnerability Protection

  • Allowlist software (e.g. Windows Defender Application Control (WDAC))
  • Antivirus software (e.g. Windows Defender)
  • Is software pre-installed?
  • Are exceptions for specific folders configured?
  • Is customer-supplied anti-virus allowed?
  • Are (Pattern-)updates provided for pre-installed software?

6.1.1 Additional Security Applications

  • Backup solutions
  • User Account Control
  • Change control
  • Intrusion prevention and detection

6.2 Network Controls

  • Description of controls implemented to protect the product and the environment from attacks:
  • Usage of security appliances
  • Firewall configuration
  • Network intrusion detection systems
  • Network segmentation

6.3 Authentication and Authorization

6.3.1 Accounts

  • Purpose of each account
  • Hidden accounts
  • Shared accounts

6.3.2 Default Accounts and Role-based Access Control

  • Description of the roles

6.3.3 Authentication Mechanisms

  • LDAP/AD directory integration
  • Public Key Infrastructure (PKI) or multi-factor authentication
  • Session timeout
  • Username/Password
    • Passwords are changeable by the customer
    • Unique passwords per product
    • Admin access for the customer
    • Requirement to change the initial password before use
    • Password policies (e.g. minimum length, complexity, expiration, reuse, etc.)

6.3.4 Break the Glass Concept

  • How does the mechanism work?
  • Where are the uses logged?

6.3.5 Data Segregation

Description of the data segregation mechanism (if applicable).

Explanation: Data segregation involves strictly separating data from different users or use cases. For example, an application could store private and personal data from users, as well as company proprietary data. These two types of data should not be stored in the same location.

6.4 Physical Protection

Description of physical protection measures that were implemented or need to be implemented by the customer, e.g.:

  • Protection of external ports
  • Access control systems
  • Environment requirements

6.5 Event/Audit Logging

List of logging capabilities of the product, for example:

  • Windows audit logging
  • Software audit trail
  • Software trace logs
  • Firewall logging
  • (Audit) log file protection against manipulation
  • External log server support (e.g. syslog)
  • Specify what events are logged and how long they are stored
  • Information in logs: e.g., user ID, date, time, and resources accessed
  • Display of logging events: displayed to the user and/or pushed to another system (e.g. log server) without delay
  • Access rules to log files

6.6 Data Protection

List of actions taken to protect personal and sensitive data.

6.6.1 Cloud/Hosted Products

  • Is data stored on company servers?
  • Where are these servers located?

6.6.2 Protection of Data in Transit 

  • Encrypted network traffic
  • Does the product send PHI or PII?
  • Specify method, algorithm, key length, shared secret, or certificate, etc.

6.6.3 Protection of Data at Rest

  • Encrypted hard disk
  • Encrypted database/data files
  • Does the product store PHI or PII?
  • Specify method, algorithm, key length, etc.

6.6.4 Protection of Exported Data

  • Encrypted backups
  • Encrypted exports
  • Specify method, algorithm, key length, shared secret or certificate, etc.

6.6.5 Additional Data Protection

  • Memory protection
  • Data integrity protection
  • Encrypted external media support

6.6.6 Data Handling at End of Life

  • Mechanisms for secure deletion of sensitive data

6.6.7 Data Handling according to GDPR

  • Information (right of access, Art. 15 GDPR)
  • Deletion (right to be forgotten, Art. 17 GDPR)
To top

7. Process Controls

Short summary of all process controls described in this document.

7.1 Disaster Prevention and Recovery

Description of all disaster prevention and recovery features and measures, including:

  • Backup and restore mechanism
  • Support for customer-supplied backup solutions
  • External storage support
  • Data compression algorithms
  • Support for multiple archive destinations
  • Automatic purging of data

7.2 Incident and Vulnerability Handling Process

  • Patch/vulnerability remediation process (vendor- or customer-supplied patches)
  • Mitigation measures (patches, workarounds)
  • Vulnerability handling process
  • Customer notification

7.3 Remote Connectivity

How is remote connectivity secured? Description of the process (including training) and the security controls. 

7.4 Compliance and Certifications

A list of the standards, certifications and regulations with which the product complies, along with those to which it does not apply, as well as the certifications it has obtained, for example:

  • Standards (IEC 80001-1, IEC 81001-5-1, etc.)
  • Certifications (RMF (formerly DIACAP, etc.)
  • Regulations (HIPAA, GDPR, AI-Act, etc.)
To top

8. Secure Configuration

8.1 Installation and Initial Configuration

Description of any security-related aspects during installation and initial configuration (can be duplicates of the information above), including:

  • Physical protection
  • Firewalls and network configuration
  • Initial passwords that need to be changed
  • Software updates that need to be installed
  • Integration into the customer’s IT infrastructure
  • Trainings that needs to be completed prior to installing or operating the product

8.2 Modifications to the System

Description of what the customers are allowed to do and how they should do it, for example:

  • Password change
  • Customer-specific protection software
  • Customer-provided printer drivers
  • Customer-provided logging solutions
  • Customer-provided anti-malware solutions
  • Customer-provided scanning solutions

The customer is responsible in the event of modifications, including requirements for revalidation.

8.3 Security Best-practices

Collection of rules for operating the product, for example:

  • Do not access the internet from the device
  • Do not expose the device directly to the internet
  • Never install unapproved software
  • Use the product only for its intended purpose
  • Do not connect radio links
  • Only change system settings if it is explicitly allowed (documented in manuals)
  • Report any strange behaviour of the product to customer services
To top

9. Attachment: MDS² Form

Manufacturer Disclosure Statement for Medical Device Security download:

https://www.nema.org/standards/view/manufacturer-disclosure-statement-for-medical-device-security 

Further information in German: 

https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/Kreise/Expertenkreis_CyberMed_MDS2.pdf?__blob=publicationFile&v=1   

To top

10. Legal Statement / Disclaimer

<disclaimer>

How to use the IT-Product Security Whitepaper Template

Users may fill in the white paper as a template with all relevant information about their product. First, general information about the system is to be provided, including hardware, software and operating system with details of the version, patch status and network configuration. The next section is to describe the basic principles and key security measures for the product. These include protection mechanisms against malware and vulnerabilities, network security, incident and vulnerability handling, and regulations for remote access. The topics of authentication and authorisation should also be examined in detail. This includes user account management, role-based access control, special mechanisms such as the ‘break the glass’ concept, and organisational data separation.

The completed document should also contain clear specifications on data protection for transmitted, stored and exported data. Also, data protection-compliant handling of information throughout the entire product life cycle should be outlined. Important aspects such as physical security, monitoring of security-related incidents through event and audit logging, disaster recovery, compliance with guidelines and certifications, and best practices for secure system configuration are part of the whitepaper and should be taken into account. The white paper can also be supplemented by a network or system diagram in which the product is integrated and a standardised MDS² form with further security information. The white paper should also include a legal notice on liability issues. 

Filled out this results in a comprehensive, practice-oriented presentation of most important security-critical areas of an IT-Product and can be used across the healthcare industry.

To top

Development and Authorship

The IT-Product Security Whitepaper Template was developed by the IT Security Working Group of the VDGH (Verband der Diagnostica-Industrie e.V.) to provide standardised guidance on product security documentation within the diagnostics industry. Consisting of industry experts and security professionals, the working group is dedicated to establishing best practices and supporting member companies in implementing comprehensive security measures for their products.

To top

Disclaimer und Feedback

This IT-Product Security Whitepaper Template is provided for reference purposes only and serves as a general template. The creator/manufacturer of the IT product is solely responsible for implementing, maintaining and ensuring the accuracy of all security measures described herein. It is worth noting that the white paper is not exhaustive, and that not all sections of the template need to be completed if they are not applicable to the product. The VDGH welcomes suggestions and feedback on how to improve the template – please contact us with your recommendations or questions to help us enhance this resource for the diagnostics community.

To top