MDR · IVDR · MDCG 2019-16 rev.1
Проектируйте кибербезопасность как свойство медицинского изделия
Соответствие не подтверждается одним испытанием на проникновение. Изготовитель должен связать архитектуру, угрозы, риски для пациента, меры контроля, верификацию, информацию для пользователя и работу с уязвимостями на протяжении всего жизненного цикла изделия.
Регуляторная основа
Начните с требований к изделию, а не с перечня тестов
MDCG 2019-16 rev.1 не создает отдельной процедуры сертификации. Руководство объясняет, как выполнять относящиеся к кибербезопасности требования Приложения I MDR и IVDR и связывать их с технической документацией, PMS и vigilance.
Регламент (ЕС) 2017/745
Медицинские изделия
- 17.2
- Жизненный цикл разработки, управление рисками, включая информационную безопасность, верификация и валидация
- 17.4
- Минимальные требования к аппаратным средствам, IT-сетям и мерам IT-безопасности, необходимым для работы ПО по назначению
- 23.4
- Информация для безопасного применения, включая требования к IT-среде и мерам защиты
Регламент (ЕС) 2017/746
Изделия для диагностики in vitro
- 16.2
- Жизненный цикл разработки, управление рисками, включая информационную безопасность, верификация и валидация
- 16.4
- Минимальные требования к аппаратным средствам, IT-сетям и мерам IT-безопасности, необходимым для работы ПО по назначению
- 20.4.1
- Информация в инструкции по применению, включая требования к IT-среде и мерам защиты
Модель соответствия
Управляйте безопасностью непрерывно, пока изделие поддерживается
Угрозы и уязвимости изменяются быстрее, чем базовая конструкция изделия. Поэтому вывод о безопасности действителен только при наличии работающих процессов мониторинга, оценки и своевременного устранения уязвимостей после выпуска.
-
01
Определите контекст
Архитектура, активы, данные, пользователи, клинические функции, интерфейсы, среда эксплуатации и срок поддержки.
-
02
Смоделируйте угрозы
Границы доверия, поверхности атаки, предвидимые сценарии, эксплуатируемость и возможное воздействие на пациента.
-
03
Снизьте риски проектированием
Минимальные привилегии, аутентификация, сегментация, защита данных, журналирование, отказоустойчивость и безопасное обновление.
-
04
Контролируйте компоненты
Стороннее и открытое ПО, происхождение версий, известные уязвимости, SBOM и управляемая замена компонентов.
-
05
Проверьте реализацию
Анализ кода, сканирование, фаззинг, испытания интерфейсов и обновлений, тестирование на проникновение и проверка остаточного риска.
-
06
Поддерживайте безопасность
Мониторинг угроз, прием сообщений, оценка уязвимостей, патчи, коммуникация, CAPA, PMS и при необходимости vigilance или FSCA.
Техническая документация
Покажите прослеживаемый путь от угрозы до проверенной меры контроля
Отдельный отчет по кибербезопасности полезен, но недостаточен. Доказательства должны согласовываться с назначением, архитектурой, требованиями к ПО, управлением рисками, верификацией, инструкцией, PMS и фактически выпущенной конфигурацией.
План кибербезопасности
Роли, процессы, критерии, методы, инструменты, поставщики, контроль изменений и действия после выпуска.
Архитектура и потоки данных
Компоненты, границы доверия, интерфейсы, протоколы, порты, внешние сервисы, облачная среда и обновления.
Модель угроз и оценка рисков
Активы, сценарии атак, уязвимости, вероятность эксплуатации, вред, меры контроля и остаточный риск.
Компоненты и SBOM
Идентификация сторонних компонентов, версии, лицензии, источники, известные уязвимости и поддерживаемость.
Отчеты верификации и валидации
Обоснованный набор методов, критерии приемки, результаты, нерешенные аномалии и повторная проверка после изменений.
Информация для безопасной эксплуатации
Поддерживаемая среда, конфигурация, сетевые требования, роли доступа, резервирование, журналирование и установка обновлений.
План работы с уязвимостями
Канал приема, триаж, сроки, согласованное раскрытие, экстренные меры, патчи и коммуникация с пользователями.
Записи PMS и vigilance
Сигналы, тенденции, инциденты, корректирующие действия, обновления оценки риска и влияние на клиническую оценку или оценку эффективности.
Среда эксплуатации
Распределите действия, но не ответственность изготовителя
Безопасность подключенного изделия зависит от изготовителя, интегратора, медицинской организации и пользователя. Изготовитель должен определить разумные предположения о среде и предоставить применимую информацию, но не может переносить на оператора риски, которые должны быть снижены конструкцией изделия.
Безопасное изделие и поддерживаемый жизненный цикл
- Определяет контекст безопасности и требования
- Реализует и проверяет меры контроля
- Поддерживает компоненты и устраняет уязвимости
- Предоставляет информацию и обновляет документацию
Контролируемая установка и конфигурация
- Следует требованиям изготовителя
- Проверяет интерфейсы и совместимость
- Документирует конфигурацию и изменения
- Передает сведения об обнаруженных проблемах
Защищенная инфраструктура и эксплуатация
- Сегментирует сеть и управляет доступом
- Поддерживает резервирование и восстановление
- Устанавливает согласованные обновления
- Реагирует на события и информирует изготовителя
Применение в установленной среде
- Соблюдает инструкции и ограничения
- Защищает учетные данные и физический доступ
- Не отключает предусмотренные меры защиты
- Сообщает о сбоях и подозрительных событиях
После вывода на рынок
Не приравнивайте уязвимость автоматически к серьезному инциденту
Полученный сигнал сначала требует технической и клинической оценки. Даже если сообщение в рамках vigilance не требуется, решение и действия должны оставаться прослеживаемыми в PMS, управлении рисками и CAPA.
-
01
Примите и сохраните сигнал
Исследователь, пользователь, поставщик, журнал, база уязвимостей, жалоба или внутренний мониторинг.
-
02
Подтвердите затронутую конфигурацию
Версии, компоненты, условия эксплуатации, доступность атаки и наличие известных случаев эксплуатации.
-
03
Оцените безопасность пациента
Воздействие на характеристики, диагностическое или терапевтическое решение, доступность и возможный вред.
-
04
Определите регуляторные действия
Обычное устранение, срочная мера, сообщение пользователям, серьезный инцидент, FSCA, тренд или иная отчетность.
-
05
Устраните и замкните обратную связь
Патч или компенсирующая мера, V&V, контролируемое распространение, обновление рисков, PMS и документации.
Опубликуйте понятный канал для сообщений, подтвердите получение, защитите конфиденциальные сведения, согласуйте сроки исправления и коммуникации и не затягивайте меры, необходимые для снижения риска.
Смежное законодательство ЕС
Разделяйте соответствие продукта и обязанности организации
MDR или IVDR остаются основой CE-маркировки медицинского изделия. Другие акты могут применяться параллельно к данным, изготовителю, медицинской организации, ИИ-системе или отдельному цифровому продукту.
Cyber Resilience Act
Регламент (ЕС) 2024/2847 не применяется к продуктам с цифровыми элементами, подпадающим под MDR или IVDR. Отдельные компоненты или платформы вне этой сферы необходимо оценивать самостоятельно.
NIS2
Директива (ЕС) 2022/2555 охватывает определенных изготовителей медицинских изделий и IVD. Применимость зависит от категории организации, размера и национального законодательства государства-члена.
GDPR
Защита персональных данных не заменяет безопасность изделия. Необходимо отдельно определить роли, правовые основания, минимизацию, права субъектов, безопасность обработки и обязанности при нарушениях.
Акт об искусственном интеллекте
Для функций на основе ИИ дополнительно оцените классификацию системы, обязанности участников, качество данных, надзор человека, устойчивость и взаимодействие с процедурой соответствия медицинского изделия.
Первоисточники и стандарты
Обосновывайте современный уровень безопасности применительно к изделию
Стандарт или руководство не следует применять механически. Определите применимость, используемую редакцию и роль каждого документа, а также проверяйте актуальный статус гармонизации до заявления о презумпции соответствия.
MDCG 2019-16 rev.1
Основное руководство ЕС по кибербезопасности медицинских изделий
Регламент (ЕС) 2017/745
Официальный текст MDR на EUR-Lex
Регламент (ЕС) 2017/746
Официальный текст IVDR на EUR-Lex
IEC 81001-5-1:2021
Действия по обеспечению безопасности в жизненном цикле медицинского ПО
ISO 14971:2019
Управление рисками медицинских изделий
IMDRF N73
Принципы и практика SBOM для кибербезопасности медицинских изделий
Часто задаваемые вопросы
Практические границы требований
Объем работ зависит от архитектуры, предполагаемой среды применения, клинической функции, поддерживаемого срока службы и последствий нарушения конфиденциальности, целостности или доступности.
Применяются ли требования только к подключенным изделиям?
Нет. Даже автономное изделие может иметь уязвимые локальные интерфейсы, съемные носители, сервисный доступ, механизм обновления или сторонние компоненты. Оценка должна отражать фактическую архитектуру и предвидимые пути атаки.
Достаточно ли испытания на проникновение?
Нет. Это один из методов верификации. Он не заменяет моделирование угроз, управление рисками, безопасную архитектуру, контроль компонентов, проверку требований, информацию для пользователя и послепродажные процессы.
Обязателен ли SBOM?
MDR и IVDR не задают единый обязательный формат SBOM. Однако MDCG 2019-16 rev.1 рассматривает его как релевантный элемент информации, а идентификация сторонних компонентов необходима для мониторинга известных уязвимостей и поддержания современного уровня безопасности.
Нужно ли сообщать о каждой уязвимости?
Не автоматически в рамках vigilance. Каждая уязвимость требует документированной оценки эксплуатируемости и возможного вреда. Отчетность зависит от применимых определений инцидента, серьезного инцидента, угрозы общественному здоровью и необходимости FSCA.
Распространяется ли Cyber Resilience Act на изделие по MDR или IVDR?
Нет. Продукты с цифровыми элементами, подпадающие под MDR или IVDR, исключены из сферы Cyber Resilience Act. Отдельные продукты или компоненты вне этой сферы должны оцениваться самостоятельно.