Кибербезопасность устаревшего медицинского оборудования: что необходимо предпринять руководителям в сфере биотехнологий и здравоохранения уже сейчас

Представьте себе больницу, где компьютерный томограф, установленный в 2010 году, до сих пор используется для чтения снимков грудной клетки. Платформа инфузионных насосов из начала 2000-х годов по-прежнему входит в перечень лекарственных средств и оборудования в десятки больниц. Обе системы продолжают приносить доход за счет контрактов на обслуживание и расходных материалов. Обе они создавались в расчете на ландшафт угроз, которого больше не существует, и обе сейчас находятся в эпицентре регуляторного и коммерческого кризиса, который производители должны осознать уже сейчас, а не в следующем году.

Давление исходит с двух сторон одновременно. Регулирующие органы США и ЕС превратили кибербезопасность из приятного дополнения к дизайну в обязательное условие доступа на рынок. Злоумышленники научились эффективнее находить самое старое и наименее защищенное устройство в сети и использовать его в качестве входной двери. Для производителя с большой базой установленного устаревшего оборудования вопрос заключается не в том, стоит ли действовать, а в том, модернизировать ли устройство, которое все еще продается, вывести его из эксплуатации или ждать, пока регулятор или хакеры заставят принять решение.

Это также коммерческий вопрос, а не только вопрос защиты. Линейка устройств с надежным, документированным профилем кибербезопасности обеспечивает годы дополнительных продаж продукта, который уже амортизирован и все еще генерирует высокую маржинальную прибыль от обслуживания. Линейка устройств, которая не соответствует текущим стандартам, рискует незаметно выпасть из списков закупок больниц, независимо от ее клинического качества.

Выбор формулируется так: «потратить деньги сейчас, чтобы сохранить проверенную линейку доходов» или «потерять ее позже по чужому сценарию».

Выбор формулируется так: «потратить деньги сейчас, чтобы сохранить проверенную линейку доходов» или «потерять ее позже по чужому сценарию».

Почему устаревшие устройства стали самой уязвимой мишенью в больницах

Здравоохранение остается самой дорогой отраслью с точки зрения утечек данных уже более десятилетия. Устаревшие устройства являются частью этой уязвимости, поскольку они проектировались в расчете на гораздо более длительные сроки, чем те угрозы, с которыми они сталкиваются сегодня. Платформа инфузионных насосов может оставаться в эксплуатации от пятнадцати до двадцати лет, работая на микропрограммном обеспечении, которое было адекватным на момент запуска и с тех пор существенно не менялось. Рецензируемый анализ оборудования, закупленного национальными службами здравоохранения, показал, что публично раскрытые уязвимости в таких устройствах обычно обнаруживаются более чем через три года после их внедрения; больницы регулярно используют оборудование, которое является уязвимым задолго до того, как об этом кто-либо узнает.

Защитите свои бизнес-операции

Модернизируйте свои системы

Несколько инцидентов делают эту картину наглядной. Вирус WannaCry (2017) использовал старую уязвимость Windows, к которой все еще были уязвимы незащищенные системы визуализации и администрирования в Национальной службе здравоохранения Великобритании (NHS), что привело к перенаправлению машин скорой помощи и отмене процедур. Инфузионный насос Medfusion 4000 (CVE-2017-12725) был разработан с учетом механической безопасности, но по своей конструкции доверял сетевым коммуникациям, что позволяло осуществлять удаленное управление при получении доступа к сети. В 2023 году компании BD, Insulet и ZOLL с разницей в несколько месяцев сообщили об уязвимостях в подключенных устройствах — и речь шла не об экзотических уязвимостях нулевого дня, а о пробелах, возникающих, когда уровень безопасности устройства не поспевает за ростом его сетевой доступности; только инцидент с ZOLL привел к утечке персональных данных чуть более чем одного миллиона человек. А атака программы-вымогателя на систему Ascension в 2024 году, которая парализовала работу примерно 140 больниц и заставила медицинские учреждения вернуться к бумажным картам, демонстрирует масштаб косвенных убытков, когда любое устройство в клинической сети становится точкой входа.

Злоумышленникам все чаще не требуется сложная уязвимость нулевого дня против самого устройства. Им нужна одна уязвимая, забытая, несегментированная система, и таковой может оказаться устройство устаревшей модели, которое невозможно пропатчить.

Обратите внимание, что самые разрушительные инциденты из упомянутых выше, такие как WannaCry и Ascension, начались не с самого медицинского устройства. Они начались с неисправленных ИТ-систем и фишинговых писем, которые являются распространенными способами начала атак перед их распространением на устройства. Проблемы, специфичные для устройств Medfusion, BD, Insulet и ZOLL, были реальными, но затронули меньшее количество систем. Тем не менее, это не означает, что медицинское устройство не сможет стать основной причиной крупной атаки в будущем.

Требования регуляторов выросли — и выросли быстро

Базовые требования к соблюдению нормативных требований резко изменились за последние два года, и три события имеют наибольшее значение.

• Раздел 524B закона FDA теперь является обязательным. Он позволяет FDA требовать информацию о кибернетической безопасности в заявках на получение разрешения до выхода на рынок для «кибернетических устройств», к которым относится практически любое устройство с программным обеспечением или сетевым подключением, охватывающее большинство современного больничного оборудования. Руководство обновлялось трижды с 2023 года, последний раз — 3 февраля 2026 года, чтобы соответствовать новому Положению FDA о системе управления качеством (QMSR, вступает в силу 2 февраля 2026 года и включает стандарт ISO 13485:2016). Основные требования остались прежними, но стали строже: в процесс проектирования должна быть внедрена структура безопасной разработки продукта (Secure Product Development Framework), необходим спецификационный состав программного обеспечения (часто с заявлением VEX), план мониторинга уязвимостей должен охватывать весь коммерческий жизненный цикл устройства, а риск кибербезопасности должен быть включен в систему качества как «разумно предвидимый риск». Теперь отсутствие элементов кибербезопасности может стать причиной отклонения заявки. FDA выпускает отказы в принятии (Refuse to Accept) из-за отсутствия SBOM или моделей угроз, а кибернетическое устройство, не соответствующее требованиям, считается фальсифицированным или неверно маркированным, что влечет за собой те же меры пресечения, что и другие нарушения качества.

• ЕС сформировал аналогичные требования на основе стандартов. Приложения I §17.2 и 17.4 регламентов MDR/IVDR уже требуют «современной» ИТ-безопасности, а основным руководящим документом является MDCG 2019-16 (Rev.1). Изменилось то, что уполномоченные органы теперь рассматривают стандарт IEC 81001-5-1:2022 в качестве де-факто стандарта доказательства выполнения этих обязательств наряду со стандартами ISO 14971 и IEC 62304. Два обновления MDCG 2025 года расширяют эту картину: одно касается безопасного распространения программного обеспечения устройств через онлайн-платформы, а другое — взаимодействия между кибербезопасностью и Законом ЕС об искусственном интеллекте для устройств с поддержкой ИИ.

ЕС сформировал аналогичные требования на основе стандартов. Приложения I §17.2 и 17.4 регламентов MDR/IVDR уже требуют «современной» ИТ-безопасности, а основным руководящим документом является MDCG 2019-16 (Rev.1). Изменилось то, что уполномоченные органы теперь рассматривают стандарт IEC 81001-5-1:2022 в качестве де-факто стандарта доказательства выполнения этих обязательств наряду со стандартами ISO 14971 и IEC 62304. Два обновления MDCG 2025 года расширяют эту картину: одно касается безопасного распространения программного обеспечения устройств через онлайн-платформы, а другое — взаимодействия между кибербезопасностью и Законом ЕС об искусственном интеллекте для устройств с поддержкой ИИ.

• Закон ЕС о киберустойчивости (CRA) имеет большое значение, даже несмотря на то, что медицинские изделия от него освобождены. CRA представляет собой горизонтальный закон о киберустойчивости для подключенных устройств, предусматривающий требования к отчетности с сентября 2026 года и полное применение с декабря 2027 года, подкрепленный штрафами в размере до 15 млн евро или 2,5% от общемирового годового оборота. Изделия, подпадающие под действие регламентов MDR/IVDR, выведены из-под его действия, поскольку MDR уже охватывает их, однако это исключение оказывается более узким, чем кажется на первый взгляд. Подключенная инфраструктура зданий, немедицинские принадлежности и общие ИТ-компоненты, которые поддерживают устройство, но сами по себе не классифицируются как таковые, полностью подпадают под действие CRA, а стандартом для такого пересечения является IEC 62443. Производителям необходимо сопоставить всю свою линейку продуктов с требованиями обоих режимов.

Закон ЕС о киберустойчивости (CRA) имеет большое значение, даже несмотря на то, что медицинские изделия от него освобождены. CRA представляет собой горизонтальный закон о киберустойчивости для подключенных устройств, предусматривающий требования к отчетности с сентября 2026 года и полное применение с декабря 2027 года, подкрепленный штрафами в размере до 15 млн евро или 2,5% от общемирового годового оборота. Изделия, подпадающие под действие регламентов MDR/IVDR, выведены из-под его действия, поскольку MDR уже охватывает их, однако это исключение оказывается более узким, чем кажется на первый взгляд. Подключенная инфраструктура зданий, немедицинские принадлежности и общие ИТ-компоненты, которые поддерживают устройство, но сами по себе не классифицируются как таковые, полностью подпадают под действие CRA, а стандартом для такого пересечения является IEC 62443. Производителям необходимо сопоставить всю свою линейку продуктов с требованиями обоих режимов.

Нормативно-правовая база вкратце:

В совокупности эти нормативные акты делают подход «ничего не предпринимать» реальным бизнес-риском. Устройство, которое не может продемонстрировать надежную защиту в области киберустойчивости, может не пройти дополнительную подачу по процедуре 510(k), провалить аудит нотифицированного органа и проиграть следующий тендер больницы, даже если оно безупречно с клинической точки зрения.

Почему подход «просто установить патч» не работает для уставшего оборудования

Большинство устаревших устройств не проектировались с учетом архитектуры, которую предполагают современные средства контроля: в них отсутствуют безопасная загрузка или цепочка подписи кода для проверки целостности программного обеспечения; используются встроенные операционные системы или ОС с завершенным сроком поддержки, которые производитель больше вообще не обновляет; отсутствует достаточная емкость для ведения журналов аудита, ожидаемая в соответствии с текущими рекомендациями; аппаратное обеспечение ограничено по памяти и не способно запускать современное шифрование без перепроектирования; кроме того, любое изменение программного обеспечения само по себе может стать поводом для подачи новой нормативной заявки.

Именно поэтому все современные стандарты сходятся в одном решении: средства контроля на основе рисков, сегментация и осознанные решения по управлению жизненным циклом, а не массовая установка патчей. В некоторые устройства стоит вложиться, чтобы привести их в соответствие. Другим лучше обеспечить компенсирующие меры контроля до окончания срока службы. Задача руководства — принять это решение осознанно, опираясь на факты.

Практический путь устранения уязвимостей для производителей

Шаг 1: Проверка соответствия нормативным требованиям и техническая оценка

Прежде чем тратить деньги на устранение несоответствий, установите факты. Это означает:

• Корректную классификацию каждого устройства в соответствии с действующими нормативными определениями: является ли оно «киберустройством» согласно разделу 524B? Подпадает ли оно под требования кибербезопасности Приложения I MDR? Подпадают ли какие-либо аксессуары или подключенные компоненты под действие CRA, а не MDR?

• Документирование обоснования такой классификации на основе рисков, чтобы оно выдержало проверку со стороны FDA или нотифицированного органа.

• Проведение анализа пробелов по сравнению с текущим базовым уровнем стандартов (ожидания в отношении SPDF/SBOM, IEC 81001-5-1, ISO 14971), чтобы точно понять текущее положение каждой линейки устройств.

• Технико-экономическое обоснование: можно ли обновить это конкретное устройство для устранения пробелов с разумными затратами, учитывая его архитектуру, или это просто недостижимо в течение оставшегося срока службы аппаратного обеспечения?

Результатом этого шага должно стать четкое, задокументированное решение для каждой линейки продукции: инвестировать и привести в соответствие, применить компенсирующие меры контроля и управлять как устаревшим оборудованием либо запланировать поэтапный вывод из эксплуатации.

Примите решение: инвестировать, изолировать или вывести из эксплуатации.

Примите решение: инвестировать, изолировать или вывести из эксплуатации.

Шаг 1 завершается либо инвестированием, либо изоляцией, либо выводом из эксплуатации. Инвестируйте и приводите в соответствие, когда установленная база велика, а архитектура способна правдоподобно поддерживать современные средства контроля. Применяйте компенсирующие меры контроля и управляйте как устаревшим оборудованием, если устройство все еще ценно, но близко к окончанию срока службы; здесь задача производителя сводится к публикации рекомендаций по сегментации, точной спецификации SBOM и оперативному реагированию на раскрытие информации даже без выпуска нового кода. Поэтапный вывод из эксплуатации применяется, когда архитектура не может соответствовать стандарту при любых разумных затратах; это делается осознанно, с объявленным графиком, а не вынужденно из-за проваленного аудита.

Шаг 2: Тестирование безопасности

Документация и анализ архитектуры дают лишь определенный результат; реальные уязвимости всплывают при тестировании. Как минимум, это означает сканирование уязвимостей программного обеспечения, прошивки и сетевых интерфейсов устройства; тестирование на проникновение настоятельно рекомендуется, а для устройств, запрашивающих предварительное разрешение на кибербезопасность в соответствии с руководящими принципами FDA 2026 года, фактически является обязательным. Этот шаг часто выявляет проблемы, о существовании которых команда разработчиков даже не подозревала, особенно в сторонних или открытых компонентах, глубоко запрятанных в программном стеке, — именно то, что призван сделать видимым SBOM.

Шаг 3: Пересмотр или создание необходимой документации

Нормативные заявки и аудиты зависят от документации. Обычно это означает обновление или создание с нуля, где это необходимо:

• Файла управления рисками по стандарту ISO 14971, который теперь явно охватывает риски кибербезопасности наряду с традиционными рисками для безопасности.

• Файла проектирования удобства использования (юзабилити) по стандарту IEC 62366.

• Спецификации состава программного обеспечения (SBOM), составленной в формате, ожидаемом регулирующими органами (CycloneDX или SPDX), в идеале в паре с заявлением VEX, определяющим, какие из перечисленных уязвимостей действительно могут быть проэксплуатированы в конкретной конфигурации устройства.

• Моделей угроз, представлений архитектуры безопасности и плана мониторинга уязвимостей, которых требуют как руководство FDA 2026 года, так и документ MDCG 2019-16.

Шаг 4: Обновление программного и, при необходимости, аппаратного обеспечения

После определения пробелов и приоритетов начинается инженерная работа: устранение выявленных уязвимостей, внедрение недостающих средств контроля (аутентификация, шифрование, механизмы безопасного обновления, ведение журналов) и, если архитектура действительно не поддерживает современные средства контроля, определение аппаратной модификации, необходимой для достижения этой цели. Биотехнологические и медицинские организации также могут работать со специализированным технологическим провайдером для создания/добавления защищенных решений или обновления старых систем, поддерживая бесперебойную работу клинических процессов. Обычно это самый ресурсоемкий этап, на котором решение «разрабатывать самостоятельно или привлекать партнеров» (описанное ниже) оказывает наибольшее финансовое влияние.

Шаг 5: Сертификация там, где это необходимо

В зависимости от масштаба изменений этот шаг может означать подачу новой заявки в FDA, уведомление нотифицированного органа о существенных изменениях в соответствии с MDR или официальную сертификацию на соответствие определенному стандарту (например, IEC 62443-4-1 или 4-2 для самого жизненного цикла безопасной разработки). Правильно выполненная классификация и обоснование на Шаге 1 делают этот этап гораздо более предсказуемым.

Шаг 6: Налаживание непрерывного процесса

Ничто из этого не является разовым проектом. Нормативные требования будут продолжать развиваться; FDA уже трижды пересматривало свои рекомендации по кибербезопасности за три года, а руководства CRA и MDCG в ЕС все еще находятся на стадии формирования. Надежная программа включает в себя:

• Постоянный процесс отслеживания изменений в нормативных актах и стандартах, относящихся к продуктовому портфелю.

• Регулярный график обновления оценок рисков и технической документации по мере появления новой информации.

• Периодическое сканирование уязвимостей и периодические тесты на проникновение, привязанные к плану мониторинга уязвимостей, уже заявленному в регуляторной документации устройства.

• Определенный процесс скоординированного раскрытия информации об уязвимостях, поскольку регуляторы по обе стороны Атлантики теперь ожидают его наличия.

От ручных аудитов к единой панели управления: узнайте, как производитель медицинского оборудования оптимизировал соответствие требованиям

Читать далее

Готовы ускорить разработку биотехнологий?

Для медицинских учреждений: более короткий и параллельный путь

Больницы и системы здравоохранения сталкиваются с похожей, но специфической версией этой проблемы: они не контролируют проектирование устройств, но они контролируют сеть, в которой находится устройство, и решение о продолжении его работы. Этот путь проще, но не менее актуален:

• Оценка инфраструктуры, программного обеспечения и парка медицинских устройств для выявления уязвимостей, пробелов в соответствии требованиям и конкретных устройств, нуждающихся в замене, изоляции или официальном уведомлении производителя об уязвимости.

• Тестирование инфраструктуры и парка устройств, как минимум сканирование уязвимостей, а при возможности и тестирование на проникновение, чтобы получить картину на основе фактических данных, а не документов.

• Устранение: сегментация сетей, чтобы устаревшие устройства не могли использоваться в качестве плацдарма, усиление контроля доступа и отслеживание нерешенных уведомлений от производителей до их закрытия.

• Поставщики медицинских услуг также несут собственные обязательства по соблюдению требований — это HIPAA, а также все чаще такие стандарты, как HITRUST, ISO 27001 и SOC 2, поскольку плательщики и партнеры требуют подтверждения наличия зрелой программы безопасности, а не просто папки с политиками.

Собственные силы против привлечения партнеров: аргументы в пользу специализированного внешнего потенциала

Каждый из описанных выше шагов может быть выполнен внутренними силами. Реальный вопрос заключается в том, является ли это самым быстрым или дешевым способом достижения цели, и для большинства производителей, управляющих несколькими линейками устаревшей продукции в условиях меняющихся требований, это обычно не так, по трем причинам.

• Узкая специализация экспертизы. Тестирование безопасности в отношении встроенных архитектур, инструменты SBOM/VEX и нормативная документация в текущем формате — это специализированные навыки. Наем и удержание таких специалистов в штате для работы, которая по своей сути носит проектный характер, происходит медленно и обходится дорого.

• Цель постоянно меняется. Только FDA пересматривало свои руководства по кибербезопасности трижды с 2023 года. Партнер, чья деятельность сосредоточена на отслеживании стандартов FDA, MDR/MDCG и грани между CRA и IEC 62443, включает это в постоянный объем услуг; внутренней команде приходится развивать эту компетенцию с нуля в дополнение к обычной работе над продуктом.

• Масштаб снижает издержки. Производитель, осуществляющий одновременную оценку, тестирование и устранение уязвимостей в нескольких линейках продукции, сталкивается с реальными ограничениями ресурсов, если направляет все это через инженерную организацию, которая также должна продолжать выпуск новых продуктов. Партнер с имеющимися инструментами и шаблонами обычно работает быстрее и, благодаря уже распределенным среди других клиентов постоянным затратам, обходится дешевле, чем создание аналогичного потенциала для портфеля одной компании.

При оценке партнера ищите опыт работы на всем пути (а не на каком-то его отдельном этапе), владение как американскими, так и европейскими стандартами, способность масштабировать команду в зависимости от фазы, а также собственный жизненный цикл разработки ПО, который сам по себе соответствует нормативам и стандартам, чтобы инструменты, используемые для создания исправления, не стали источником дополнительных рисков.

Итог

Упомянутые устройства никуда не денутся в ближайшее время; они клинически ценны, за них заплачено, и замена всей установленной базы за одну ночь нереальна ни для производителей, ни для больниц. Однако нормативная среда и ландшафт угроз вокруг них кардинально изменились за последние два года и будут продолжать меняться. Производители, которые относятся к этому как к структурированной программе на основе рисков (оценка, тестирование, документирование, устранение, сертификация, мониторинг), смогут сохранить свои линейки устаревшей продукции пригодными для продажи и соответствующими требованиям далеко за пределами срока, на который была рассчитана их исходная архитектура. Производители, которые относятся к этому как к второстепенной задаче, обнаружат, что регулятор, нотифицированный орган или злоумышленник принимают решение за них, в неудобные для них сроки и по непомерной цене.

Получите свое решение для здравоохранения