В конце июня 2025 года FDA опубликовало обновленное руководство «Кибербезопасность в медицинских устройствах: аспекты системы качества» и содержание предпродажной документации. В этом руководстве FDA подчеркивает, что риски и уязвимости кибербезопасности будут учитываться в модели угроз. Должны быть реализованы процедуры кибербезопасности для поддержки продуктов от первоначального проектирования до конца срока службы. Адекватные средства защиты кибербезопасности должны быть предусмотрены во входных данных проекта во время разработки, а не «прикручены» после завершения разработки.
Если вы являетесь разработчиком или производителем, который несет или будет нести ответственность за подключенное медицинское устройство, процесс кибербезопасности — это то, во что вам нужно вложить усилия прямо сейчас.
Существует множество стандартов, таких как ANSI/AAMI SW96:2023 и IEC 81001-5-1:2021, широко признанных в США и ЕС, которые подробно описывают, какие действия и результаты следует учитывать при оценке рисков кибербезопасности для программного обеспечения медицинского оборудования. Эта короткая статья посвящена тому, как выполнить анализ, который является основной частью модели угроз кибербезопасности. Цель этой статьи — предоставить представление о проведении анализа рисков безопасности, который будет иметь значение для всего срока службы медицинского устройства или программного обеспечения медицинского устройства.
Планирование кибербезопасности устройств
С предрыночной точки зрения ключевыми элементами анализа безопасности являются следующие:
Рисунок 1. Этапы кибербезопасности при анализе рисков
В дополнение к планированию кибербезопасности компаниям, производящим медицинское оборудование, теперь необходимо внедрить выбранную структуру в свою систему качества. Чтобы достичь уровня соответствия, некоторые компании совершают ошибку, инвестируя в универсальное программное обеспечение, но это, скорее всего, может упустить из виду истинные потребности в обеспечении кибербезопасности в вашей организации. Комплексное решение представляет собой применение концепции безопасной разработки продуктов, которая учитывает действия и задачи на протяжении всего жизненного цикла продукта (TPLC). Необходимо выделить ресурсы для разработки и обновления процессов и СОП, но основой надежного процесса является создание эффективного и действенного метода оценки рисков. Метод оценки риска представлен как Оценка риска безопасности в аналитическом разделе рисунка 1.
Сосредоточьтесь на активах в таблице анализа безопасности
Оценка рисков безопасности используется для выявления потенциальных средств управления рисками безопасности и выявления уязвимостей. Должны быть созданы две таблицы: таблица оценки рисков, которая идентифицирует и поддерживает меры контроля рисков безопасности, и таблица текущих уязвимостей, отслеживающая текущие уязвимости. Две аналитические таблицы могут находиться на отдельных вкладках простой электронной таблицы, поскольку они имеют возможности фильтрации и сортировки, позволяющие осуществлять долгосрочное управление таблицами. Содержимое Таблицы оценки рисков отражено в Таблице 1, посвященной мерам безопасности.

Таблица 1 – Таблица анализа оценки рисков безопасности
В центре внимания оценки рисков безопасности должны быть активы, определенные в архитектуре безопасности, и то, как угрозы могут использовать уязвимости для компрометации активов.
Активы — это элементы, представляющие ценность для пользователя, пациента, пользовательской организации и бизнеса и имеющие отношение к безопасности. Активы обычно могут включать в себя:
- Данные, обрабатываемые и хранящиеся в продукте (например, журналы, клиентские или эксплуатационные данные, данные конфигурации)
- Данные личного характера (например, Защищенная медицинская информация/ЗМИ)
- Информация об учетных данных (например, пароли, учетные данные, ключи)
- Программное обеспечение/прошивка продукта
- Сторонние сервисы (например, облачные сервисы, библиотеки с открытым исходным кодом, API).
Анализ должен включать разумно практические угрозы для каждого из активов. Модель STRIDE можно применять для выявления потенциальной угрозы в каждой строке анализа. Стандартная модель STRIDE и желаемое свойство безопасности представлены в Таблице 2 ниже.

Таблица 2 – Определения шага
Идентификация уязвимостей
В дополнение к оценке рисков безопасности следует вести отдельную таблицу текущих уязвимостей, как упоминалось ранее. В этой таблице собраны известные уязвимости, обнаруженные в устройстве. Уязвимости — это недостатки или слабости, которые могут быть использованы потенциальными источниками угроз. Уязвимости можно обнаружить с помощью:
- Выявление уязвимостей при оценке рисков безопасности
- анализ проникновения кибербезопасности и тестирование продукта
- посредством статического анализа сканирования программного обеспечения собственной разработки с помощью инструмента SAST (статическое тестирование безопасности приложений).
- посредством сканирования динамического анализа с помощью инструмента DAST (динамическое тестирование безопасности приложений).
- рассмотрение существующих каталогов, таких как Общий список уязвимостей и подверженностей, Национальная база данных уязвимостей (NVD), National Health ISAC и примечания к выпуску SOUP/COTS.
- выявлено посредством сканирования уязвимостей с использованием инструмента SCA (анализ состава программного обеспечения) для OTS или компонентов с открытым исходным кодом.
Оценка известных уязвимостей необходима перед выпуском любого продукта и поддерживается до тех пор, пока продукт не будет снят с производства. По мере выявления и устранения уязвимостей их можно удалять из таблицы текущего анализа уязвимостей. Действия над уязвимостями определяются определением серьезности уязвимости и CVSS счет. Модель оценки CVSS определяет шесть базовых элементов в своей матрице для каждой из выявленных уязвимостей: вектор атаки (AV), сложность атаки (AC), требуемые привилегии (PR), взаимодействие с пользователем (UI), область действия (S) и воздействие (CIA), измеряющие конфиденциальность, целостность и потерю доступности.
Определить влияние угроз
При анализе рисков безопасности мы знаем, что риск представляет собой сочетание серьезности и вероятности вреда (Риск = P x S). Однако для анализа рисков безопасности FDA рекомендует учитывать возможность использования потенциальной уязвимости, а не вероятность успешной атаки. Возможность использования должна основываться на том, насколько уязвима система для взлома. Чем лучше контроль безопасности, тем ниже риск. Оценка приемлемости угроз активам и уязвимостям должна основываться на матрице таблицы, аналогичной таблице 3, в зависимости от серьезности ущерба и возможности использования.

Таблица 3 – Таблица решений по возможности использования безопасности и серьезности
Более высокие риски потребуют документированного контроля рисков в таблице оценки рисков безопасности, чтобы снизить вероятность их использования и общий риск. Затем средства контроля рисков должны определять требования к проекту, а их эффективность впоследствии проверяется в ходе проверки проекта.
Заключение
Анализ рисков и уязвимостей безопасности следует вести в двух таблицах: одна необходима для выявления и поддержки рисков безопасности, а другая представляет собой постоянный список уязвимостей, которые требуют периодических обновлений после выпуска. Эти две аналитические таблицы необходимо периодически обновлять, а текущий список уязвимостей необходимо обновлять и уведомлять клиентов во время обслуживания продукта.
Независимо от того, только начинает ли ваша компания или находится на более высоком уровне зрелости кибербезопасности, создавая надежную и эффективную структуру кибербезопасности, сосредоточить внимание на формате и основных методах анализа в качестве приоритета, что приведет к лучшим решениям по инструментам и повышению эффективности процессов и компетентности.
Фото: Траитов, Getty Images
Боб Барреттвице-президент по системной инженерии в Полный спектрявляется опытным инженерным руководителем и строителем команды, ориентированным на результат. Он обладает техническими знаниями, накопленными за более чем 30 лет работы в области проектирования систем медицинского оборудования, проверки систем и программного обеспечения, анализа рисков безопасности, управления качеством и управления проектами. Боб проработал 15 лет в подразделении доставки лекарств Бакстера, где возглавлял группу системного проектирования. Боб выполняет роль тренера игроков в Full Spectrum, возглавляя команду системных инженеров и одновременно делясь своими глубокими знаниями непосредственно с клиентами. Боб твердо верит в методы управления проектами, основанные на каденции. Его способность быть практическим специалистом или руководить межфункциональными группами ускоряет реализацию программ медицинского развития клиента от концепции до выпуска на рынок.
Это сообщение появляется через Влиятельные лица MedCity программа. Любой может опубликовать свой взгляд на бизнес и инновации в здравоохранении в MedCity News через влиятельных лиц MedCity. Нажмите здесь, чтобы узнать, как.
2025-10-30 14:13:00
1761879578
#Проведение #оценки #рисков #безопасности #медицинского #оборудования
Продолжение темы


