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

Клиника знает о человеке больше, чем банк. Фамилия, телефон и номер полиса — обычные персональные данные, они есть и у магазина. А вот диагноз, результаты анализов, сведения о беременности или о психическом здоровье закон относит к специальным категориям (статья 10 Федерального закона от 27.07.2006 № 152-ФЗ). Сверх того сам факт обращения гражданина за оказанием медицинской помощи, состояние его здоровья и диагноз составляют врачебную тайну (часть 1 статьи 13 Федерального закона от 21.11.2011 № 323-ФЗ). Утечка базы пациентов бьёт по людям сильнее, чем утечка списка покупателей: диагноз нельзя сменить, как скомпрометированную карту.

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

Порядок оценки задан методическим документом ФСТЭКФедеральная служба по техническому и экспортному контролю — Регулятор технической защиты информации (ИСПДн, ГИС, КИИ); ведёт реестр сертифицированных СЗИ. России «Методика оценки угроз безопасности информации» (утверждён ФСТЭК России 05.02.2021; карточка документа). Дальше все ссылки на пункты — из него.

Клиника, на которой будем разбирать

«Клиника на Садовой» — общество с ограниченной ответственностью. Сорок пять работников, одно здание, лицензия на медицинскую деятельность. В базе около 28 000 пациентов. Устроено всё так:

• медицинская информационная система на сервере в отдельной комнате — карты пациентов, приёмы, назначения, результаты исследований;
• рабочие места: три в регистратуре, двенадцать в кабинетах врачей, два в бухгалтерии — там учётная система и клиент-банк;
• сайт с онлайн-записью: пациент оставляет имя, телефон и выбирает врача;
• электронная почта — направления, результаты, переписка со страховыми компаниями;
• съёмные носители: выгрузки для страховых, резервные копии базы;
• видеонаблюдение в холле и коридорах;
• Wi-Fi: гостевой для пациентов и рабочий для врачей, оборудование одно;
• поддержку медицинской системы ведёт компания-разработчик, у её инженеров есть удалённый доступ к серверу;
• сведения об оказанной помощи уходят в государственные системы здравоохранения по защищённому каналу.

Если ваша клиника устроена иначе — меняйте детали. Порядок рассуждения останется тем же.

Что собрать до начала

Методика перечисляет исходные данные для каждого этапа (пункты 3.2, 4.2, 5.1.2, 5.3.2). Если перевести на обычный язык, до начала работы нужны пять вещей:

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

Собрать это — половина работы. Без такого описания модель угроз превращается в сочинение на тему безопасности. С ним — в расчёт, который можно проверить.

Шаг 1. Очертить границу: что именно оцениваем

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

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

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

Дальше важная тонкость. Государственные системы здравоохранения, куда клиника передаёт сведения, внутрь границы не попадают: ими клиника не управляет. Это смежная система. Но пункт 2.13 требует включить в модель угрозы, связанные с интерфейсами взаимодействия со смежными системами. То есть сам канал передачи, узел, который его держит, и учётные данные для него — наши, и в модели они есть.

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

Шаг 2. Назвать, что плохого может случиться

Этап первый по Методике (пункт 2.15) — негативные последствия. Не угрозы, не хакеры, а события, которые по-настоящему навредят. Методика прямо требует конкретизировать их применительно к деятельности оператора (пункт 3.5) и приводит типовые виды ущерба в приложении 4: У1 — ущерб физическому лицу, У2 — риски организации, У3 — ущерб государству.

Для клиники «нарушение конфиденциальности персональных данных» — слишком общо. Пишем по-человечески:

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

Второе последствие в этом списке для клиники важнее первого, хотя вспоминают о нём реже. Утечка неприятна, а подменённый результат анализа опасен. Из этого потом вырастут совсем другие меры: не только разграничение доступа, но и контроль целостности с резервным копированием.

Здесь же пригодится отдельная обязанность оператора — оценить вред, который может быть причинён субъектам в случае нарушения закона, и соотнести его с принимаемыми мерами (пункт 5 части 1 статьи 18.1 Федерального закона от 27.07.2006 № 152-ФЗ). Степени вреда и закрытый перечень оснований установлены приказом Роскомнадзора от 27.10.2022 № 178.

Здесь легко ошибиться, и ошибаются часто. Обработка специальных категорий действительно названа основанием высокой степени вреда — но с оговоркой: «за исключением случаев, установленных федеральными законами, предусматривающими цели, порядок и условия обработки специальных категорий персональных данных» (подпункт 2.1 пункта 2). А для медицины такой случай прямо предусмотрен: обработка в медико-профилактических целях, для установления диагноза и оказания медицинских услуг лицом, которое профессионально занимается медицинской деятельностью и обязано сохранять врачебную тайну (пункт 4 части 2 статьи 10 Федерального закона № 152-ФЗ). Поэтому «высокая» не выдаётся клинике автоматически — применимость оговорки надо проверить по своим целям обработки. Обратный вывод тоже неверен: остальные основания пункта 2 проверяются все, а если подходит несколько, берётся более высокая степень (пункт 6). Пройти перечень оснований и получить формулировку для акта помогает калькулятор оценки вреда, подробный разбор — в отдельной статье.

И не смешивайте две шкалы. Степень вреда по приказу № 178 и уровень защищённости по постановлению Правительства Российской Федерации от 01.11.2012 № 1119 считаются по разным правилам: высокая степень вреда сама по себе не даёт первый уровень защищённости. Связь между ними всё же есть, но косвенная — тип актуальных угроз оператор определяет с учётом проведённой оценки вреда (пункт 7 постановления № 1119).

Шаг 3. Перечислить, на что будут воздействовать

Этап второй — объекты воздействия: ресурсы и компоненты, доступ к которым или воздействие на которые приведёт к названным последствиям (пункт 4.1). Группы объектов перечислены в пункте 4.3, определяются они на аппаратном, системном и прикладном уровнях, на уровне сети и на уровне пользователей (пункт 4.6). Для каждого объекта называются виды воздействия — что именно с ним можно сделать (пункт 4.5).

У нашей клиники получается такой перечень:

• Данные. База медицинской системы с картами пациентов. Резервные копии. Выгрузки для страховых. Учётные записи и пароли работников. Воздействие: утечка, изменение, уничтожение, блокирование.
• Прикладные программы. Медицинская система, учётная система, клиент-банк, почтовый клиент, сайт с формой записи. Воздействие: нарушение работы, подмена, использование уязвимости.
• Системное ПО и компьютеры. Сервер, рабочие места регистратуры и врачей, операционные системы. Воздействие: заражение, вывод из строя, получение чужих прав.
• Сеть и телекоммуникационное оборудование. Локальная сеть, Wi-Fi, маршрутизатор, канал в государственные системы здравоохранения, канал удалённого доступа разработчика. Воздействие: перехват, подмена участника, отказ в обслуживании.
• Носители. Флешки и внешние диски с выгрузками и копиями. Воздействие: утрата, копирование, восстановление стёртого.
• Средства защиты. Антивирус, межсетевой экран, средство защиты канала и консоль управления ими. Методика выделяет их в отдельную группу (подпункт «е» пункта 4.3): отключённая защита — это отдельная цель нарушителя.
• Обеспечивающие системы (подпункт «з» пункта 4.3). Электропитание серверной, кондиционирование, охрана, канал связи провайдера. Воздействие: остановка сервера и приёма без всякого взлома.
• Люди. Регистратор, врач, бухгалтер, администратор, инженер разработчика. Воздействие: обман, подкуп, ошибка, злоупотребление правами.

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

Шаг 4. Решить, кто может это сделать

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

Список выглядит пугающе, но применяется просто: нарушитель актуален, если возможные цели реализации им угроз ведут к нашим негативным последствиям (пункт 5.1.4, цели — в приложении 6). Рассуждаем вслух.

• Отдельные физические лица — да. Клиника видна из интернета: сайт, почта, форма записи. Цель обычная — деньги: зашифровать базу и потребовать выкуп либо продать выгрузку.
• Преступные группы — да. Базы пациентов продаются, а сведения о диагнозе годятся для шантажа.
• Авторизованные пользователи — да. Регистратор видит карты, а любопытство и подработка на стороне никуда не делись.
• Бывшие работники — да, особенно врачи, уходящие вместе со «своими» пациентами в соседнюю клинику.
• Лица, привлекаемые для настройки и обслуживания, и разработчики системы — да. У инженеров подрядчика есть удалённый доступ к серверу, а у разработчика — знание системы изнутри.
• Конкурирующие организации — да, но отдельного пути у них нет: они действуют через бывшего работника или через тех же преступных исполнителей.
• Специальные службы иностранных государств — решаем по целям, а не по ощущению «нас это не касается». Наши негативные последствия — вред пациентам и убытки клиники; целей, ради которых такой нарушитель пошёл бы именно сюда, мы не нашли, и вывод записывается в модель с обоснованием. Если бы клиника обслуживала, например, должностных лиц органов власти, вывод мог бы оказаться другим.

Дальше — уровень возможностей. Методика делит нарушителей на четыре уровня: базовые возможности (Н1), базовые повышенные (Н2), средние (Н3), высокие (Н4). Уровень определяется компетентностью, оснащённостью ресурсами и мотивацией (пункт 5.1.5), а какой вид нарушителя какому уровню обычно соответствует — показано в таблице 8.1 приложения 8. Для одной системы актуальными могут быть нарушители разных уровней, и у нашей клиники так и выходит:

• Н1 — хакер-одиночка, авторизованные пользователи, бывшие работники, обслуживающий персонал. Работают известными уязвимостями и общедоступными инструментами.
• Н2 — преступные группы, конкурирующие организации и лица, привлекаемые для установки, настройки и обслуживания, то есть инженеры поддержки. Владеют готовыми наборами инструментов и планируют сценарии сами.
• Н3 — разработчики программных средств. Разработчик медицинской системы знает её код и архитектуру, и приложение 8 относит этот вид к средним возможностям.
• Н4 — специальные службы иностранных государств. Этот вид мы отклонили выше по целям, поэтому уровень в модели не появляется.

Соблазн написать «везде Н4» кажется безопасным: взяли по максимуму, никто не придерётся. На деле Методика предупреждает об этом прямо: завышение прогнозов влечёт неоправданные расходы на нейтрализацию неактуальных угроз, занижение — непрогнозируемый ущерб (приложение 2). Решает не размер клиники и не стоимость защиты, а вид нарушителя и его цели: сначала отвечаем, актуален ли он, и только потом смотрим уровень по приложению 8.

Осталось деление на категории по доступу (пункт 5.1.6): внешние нарушители не имеют прав доступа в помещения и к ресурсам, внутренние — имеют, в том числе с административными правами. Регистратор и инженер подрядчика, которому доступ выдали, — внутренние. Вымогатель из интернета — внешний. И ещё одно различие пригодится дальше: внешний нарушитель действует всегда преднамеренно, а внутренний может навредить и по ошибке (пункт 5.1.7).

Шаг 5. Понять, через что нарушитель войдёт

Способ реализации — это то, чем нарушитель пользуется. Методика называет девять основных способов (пункт 5.2.3); для клиники из них важны прежде всего эти: использование уязвимостей, внедрение вредоносных программ, нарушение безопасности при поставках и обслуживании, ошибочные действия при эксплуатации. Остальные — закладки, скрытые каналы, перехват побочных излучений — в модели тоже рассматриваются, но обычно отклоняются с обоснованием.

Условие, при котором способ вообще работает, — доступ к интерфейсу объекта (пункт 5.2.4). Интерфейсы бывают внешние сетевые, внутренние сетевые, пользовательские, для съёмных носителей и периферии, для установки и обслуживания, а также доступ к компонентам, отданным на ремонт.

Выписываем интерфейсы клиники честно, включая те, о которых не принято вспоминать:

• сайт с формой записи — внешний сетевой интерфейс, открыт всему интернету;
• электронная почта — внешний интерфейс, ведущий прямо на рабочее место человека;
• канал в государственные системы здравоохранения — внешний интерфейс к смежной системе;
• удалённый доступ разработчика — интерфейс для обслуживания, самый мощный из всех: у него права администратора;
• гостевой Wi-Fi, если он не отделён от рабочей сети, — внешний интерфейс внутри здания, доступный любому в очереди;
• рабочие места регистратуры и врачей — пользовательские интерфейсы;
• USB-порты — интерфейс для съёмных носителей;
• сервер, увезённый в ремонт с диском внутри, — тот самый «доступ к компонентам, находящимся на обслуживании».

Этот список — половина будущей защиты. Каждая строка либо закрывается мерой, либо остаётся дырой, про которую вы хотя бы знаете.

Шаг 6. Подобрать угрозы из банка данных ФСТЭК

Теперь можно брать угрозы. Основной каталог — банк данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru), он прямо назван в исходных данных (пункт 3.2). Единственным источником он не является: там же названы модели угроз, разрабатываемые ФСТЭК России, и отраслевые модели, а пункт 5.3.2 добавляет сведения о способах реализации угроз и результаты анализа защищённости. Отсутствие подходящей карточки в банке не доказывает, что угрозы нет.

Выписывать весь банк подряд тоже бессмысленно: часть угроз относится к суперкомпьютерам, контейнерам и промышленным системам, которых в клинике нет. Ручной перебор — это несколько вечеров. Сузить перечень помогает фильтр угроз БДУ: он ставит те же вопросы, что и Методика, и отсекает лишнее. На 21 сентября 2026 года в банке 222 действующие угрозы. Дальше по шагам:

• отмечаем категории объектов, которые у нас есть: данные, системное и прикладное ПО, сеть, компьютеры и серверы, носители, система в целом. Виртуализации, контейнеров и промышленных систем в клинике нет — остаётся 161 угроза;
• первый проход делаем по карточкам с низким потенциалом — это самые массовые угрозы, доступные любому. Остаётся 92;
• вторым проходом снимаем это ограничение. Отсекать карточки со средним потенциалом не за что: среди наших нарушителей есть подготовленные — преступные группы, инженеры поддержки, разработчик системы. Вместе получается 153 угрозы.

Две оговорки, без которых фильтр вводит в заблуждение.

Потенциал в банке и уровни Н1–Н4 — разные шкалы. В карточке БДУБанк данных угроз безопасности информации ФСТЭК — Государственный реестр угроз (УБИ) и уязвимостей на bdu.fstec.ru; используется при построении модели угроз. потенциал грубый: низкий, средний, высокий. Уровень возможностей нарушителя определяется по приложению 8 Методики и из поля карточки не выводится, как и наоборот. Пользуйтесь фасетом, чтобы быстро отобрать кандидатов, а не чтобы сопоставить одну шкалу с другой: отсечённая карточка со средним потенциалом — это потерянная угроза, а не сэкономленное время.

Нельзя оставлять только конфиденциальность. Соблазнительно отметить одно свойство и получить обозримые 59 карточек. Но мы сами написали на шаге 2, что подменённая карта и остановленный приём для клиники опаснее утечки, а угроз, нарушающих целостность или доступность, в той же выборке 67. Фильтр по одному свойству годится как отдельный проход, а не как итог.

Числа приведены на дату: банк пополняется, и ваш результат может отличаться.

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

• учётная система на сервере — УБИУгроза безопасности информации — Совокупность условий и факторов, создающих опасность нарушения безопасности информации; каталогизируются в БДУ..192 «Угроза использования уязвимых версий программного обеспечения», УБИ.088 «Угроза несанкционированного копирования защищаемой информации», УБИ.074 «Угроза несанкционированного доступа к аутентификационной информации», УБИ.071 «Угроза несанкционированного восстановления удалённой защищаемой информации», УБИ.178 «Угроза несанкционированного использования системных и сетевых утилит»;
• сайт со сбором персональных данных — УБИ.041 «Угроза межсайтового скриптинга», УБИ.042 «Угроза межсайтовой подделки запроса», УБИ.017 «Угроза доступа/перехвата/изменения HTTP cookies», УБИ.173 «Угроза спама веб-сервера», УБИ.130 «Угроза подмены содержимого сетевых ресурсов»;
• удалённый доступ — УБИ.116 «Угроза перехвата данных, передаваемых по вычислительной сети», УБИ.069 «Угроза неправомерных действий в каналах связи», УБИ.034 «Угроза использования слабостей протоколов сетевого/локального обмена данными», УБИ.168 «Угроза кражи учётной записи доступа к сетевым сервисам», УБИ.131 «Угроза подмены субъекта сетевого доступа»;
• электронная почта — УБИ.175 «Угроза фишинга», УБИ.190 «Угроза внедрения вредоносного кода за счёт посещения заражённых сайтов», УБИ.186 «Угроза внедрения вредоносного кода через рекламу, сервисы и контент»;
• съёмные носители — УБИ.088, УБИ.156 «Угроза утраты носителей информации», УБИ.158 «Угроза форматирования носителей информации», УБИ.071;
• видеонаблюдение — УБИ.116 и УБИ.088 применительно к видеопотоку и архиву записей.

Заготовка не заменяет решения. Машина отбирает кандидатов по признакам, а человек отвечает на главный вопрос Методики: возможна ли эта угроза именно у нас. Угроза считается возможной, когда есть нарушитель, объект воздействия, способ реализации и негативные последствия (пункт 5.3.3). Нет объекта — нет и угрозы, и это решение записывается с обоснованием.

Заодно проверьте, что берёте именно угрозы, а не уязвимости: это разные перечни с разной нумерацией, их регулярно путают — разбор различий есть в отдельной статье.

Шаг 7. Написать сценарии

Вот место, где большинство самодельных моделей обрывается, — и именно оно решает всё. Актуальность угрозы определяется наличием сценариев её реализации (пункт 5.3.4). На этапе создания системы нужен хотя бы один сценарий для каждого способа реализации возможной угрозы, и определяется он для каждого актуального нарушителя и его уровня возможностей (пункт 5.3.5).

Для действующей клиники правило строже. На этапе эксплуатации для каждой возможной угрозы определяется множество сценариев — по результатам инвентаризации, анализа уязвимостей и тестирования на проникновение (вторая часть пункта 5.3.5, порядок — в пункте 5.3.6). Поэтому три разобранных ниже сценария — это образец рассуждения, а не доказательство того, что модель полна. И «сценария нет» означает «мы искали и обосновали, что его нет», а не «мы не стали искать».

Сценарий записывается последовательностью тактик и техник из приложения 11. Тактики — это крупные шаги: сбор информации (Т1), получение первоначального доступа (Т2), внедрение и исполнение вредоносных программ (Т3), закрепление (Т4), повышение привилегий (Т6), продвижение к другим компонентам (Т8), сбор и вывод информации (Т9), несанкционированное воздействие (Т10). Внутри каждой тактики перечислены конкретные техники с номерами вида Т1.1. Это не формальность: расписав цепочку, вы увидите, в каком звене её дешевле всего оборвать.

Сценарий 1. Вымогатель через почту регистратуры

Нарушитель: внешний, отдельное физическое лицо, базовые возможности (Н1). Цель: получить выкуп.

Ход. Т1 — нарушитель собирает сведения из публичных источников (техника Т1.1): на сайте клиники есть фамилии врачей, адрес регистратуры и общий почтовый ящик. Т2 — на этот ящик приходит письмо «результаты исследования во вложении» (УБИ.175). Регистратор открывает вложение, потому что именно такие письма он открывает весь день. Т3 — запускается вредоносная программа. Т6 и Т8 — на рабочем месте и на сервере остались необновлённые версии программ с известными уязвимостями (УБИ.192), нарушитель получает права администратора и доходит до сервера: сеть не разделена, и служба базы данных доступна с любого рабочего места. Т10 — база медицинской системы шифруется (УБИ.170 «Угроза неправомерного шифрования информации»), вместе с ней шифруется и резервная копия, поскольку лежит на том же сервере под той же учётной записью.

Последствия: приём остановлен, карты недоступны, деньги за день не получены. Угроза актуальна.

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

Сценарий 2. Регистратор смотрит чужую карту

Нарушитель: внутренний, авторизованный пользователь, базовые возможности (Н1). Цель: любопытство или заработок на стороне.

Ход. Доступ уже есть, взламывать нечего. Т9 — регистратор открывает карту известного человека и выгружает список пациентов профильного врача (УБИ.088), потому что права выданы на всю базу, а не на своё рабочее место. Т10 — выгрузка уходит на личную флешку или вместе с резервной копией покидает клинику (УБИ.156). Стёртый файл на возвращённой флешке восстанавливается бесплатной программой (УБИ.071).

Последствия: нарушена врачебная тайна, у клиники — штраф и потеря репутации. Угроза актуальна.

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

Сценарий 3. Через доступ подрядчика, который обслуживает систему

Здесь важно не смешать трёх разных нарушителей, хотя вход у них общий.

Нарушитель А: инженер подрядчика. Доступ ему выдан, значит по пункту 5.1.6 он внутренний нарушитель с административными правами, уровень Н2. Нарушитель Б: посторонний, завладевший его учётными данными, — внешний. Нарушитель В: тот же инженер, но действующий без умысла: внутренний нарушитель может навредить и по ошибке (пункт 5.1.7), а неверная команда при обслуживании базы уничтожает данные не хуже атаки.

Ход для нарушителя Б. У инженеров общая учётная запись, пароль знают несколько человек, доступ открыт круглосуточно. Т2 — учётные данные утекают или подбираются (УБИ.168), нарушитель подключается под видом легального специалиста (УБИ.131). Т1 и Т9 — канал не защищён средством криптографической защиты, поэтому трафик в нём доступен для перехвата и изменения на участках, которые клиника не контролирует (УБИ.116, УБИ.069). Т10 — база выгружается целиком, и в журналах это выглядит как обычная плановая работа поддержки: следы есть, но отличить их от нормальной работы нечем.

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

Где рвётся: именные учётные записи вместо общей, доступ по заявке и на время работ, защищённый канал, запись действий подрядчика и договор поручения обработки с условиями по статье 6 Федерального закона № 152-ФЗ.

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

Шаг 8. Что из модели следует дальше

Модель угроз — не конечная точка. Из неё выводятся три вещи.

Тип актуальных угроз и уровень защищённости. Постановление № 1119 делит угрозы на три типа по тому, связаны ли они с недекларированными возможностями: в системном программном обеспечении — первый тип, в прикладном — второй, не связаны — третий (пункт 6). Тип определяет оператор с учётом оценки вреда (пункт 7). Наши сценарии обходятся уязвимостями, фишингом и чужими правами, но одного этого мало: чтобы записать третий тип, нужно отдельно обосновать, почему угрозы, связанные с недекларированными возможностями системного и прикладного ПО, для вашей системы неактуальны. Это обоснование — часть модели, а не строчка в таблице.

Когда третий тип обоснован, дальше арифметика: специальные категории, субъекты не работники клиники, их меньше 100 000 — третий уровень защищённости (подпункт «в» пункта 11 постановления № 1119). Проверить на своих числах можно в калькуляторе уровня защищённости, сами уровни разобраны в отдельной статье. Порядок именно такой: модель угроз даёт тип, тип вместе с категорией данных и числом субъектов даёт уровень, уровень даёт базовый набор мер.

Состав мер. Базовый набор мер для установленного уровня приведён в приложении к приказу ФСТЭК России от 18.02.2013 № 21. Дальше набор адаптируют с учётом того, как устроена система, — исключают меры, связанные с технологиями и характеристиками, которых у неё нет; уточняют, возвращая ранее не выбранные меры, пока набор не закроет все актуальные угрозы; дополняют тем, что требуют другие акты (пункт 9). Если меру нельзя реализовать технически либо она неоправданна экономически, разрабатывают компенсирующую меру — и обосновывают не её дешевизну, а то, что она нейтрализует ту же актуальную угрозу (пункт 10). Именно здесь тщательная модель угроз возвращает вложенное время: исключение меры обосновывается ссылкой на модель, а не словами «у нас маленькая клиника».

Класс средств защиты. Если вы применяете сертифицированные по требованиям безопасности информации средства защиты, то для третьего уровня это средства 6 класса и 6 уровня доверия, а средства вычислительной техники — не ниже 5 класса (пункт 12 приказа № 21 в редакции приказа ФСТЭК России от 14.05.2020 № 68). Подобрать сертифицированное средство нужного класса можно в реестре сертифицированных средств защиты, а разобраться с классом и уровнем доверия — в отдельном калькуляторе. Для защиты канала в государственные системы здравоохранения понадобится средство криптографической защиты: его класс подскажет калькулятор класса СКЗИ, конкретные требования смотрите в правилах подключения к самой системе, а порядок поэкземплярного учёта разобран в статье об учёте СКЗИ.

Клиника и критическая информационная инфраструктура

Про это забывают, а норма прямая. Субъекты критической информационной инфраструктуры — в том числе российские юридические лица, которым на праве собственности, аренды или ином законном основании принадлежат информационные системы, функционирующие в сфере здравоохранения (пункт 8 статьи 2 Федерального закона от 26.07.2017 № 187-ФЗ в редакции Федерального закона от 07.04.2025 № 58-ФЗ). Частная клиника — общество с ограниченной ответственностью со своей медицинской информационной системой — под это описание попадает. Индивидуальный предприниматель не попадает: в норме названы юридические лица, государственные органы и государственные учреждения.

Быть субъектом не значит категорировать всё подряд. Категорируют не клинику, а её объекты, и с 16 ноября 2025 года — не любые: категорированию подлежат объекты, соответствующие типам из перечней типовых отраслевых объектов (пункт 3 Правил, утверждённых постановлением Правительства Российской Федерации от 08.02.2018 № 127, в редакции постановления Правительства Российской Федерации от 07.11.2025 № 1762). Сами перечни утверждены распоряжением Правительства Российской Федерации от 26.02.2026 № 360-р.

Для клиники ответ в этом перечне есть. В сфере здравоохранения среди типовых объектов назван тип «Информационные системы медицинских организаций» — системы, которые автоматизируют оказание и учёт медицинской помощи и содержат сведения о пациентах. Медицинская система нашей клиники ему соответствует, значит категорирование проводится, и по его итогам объекту либо присваивается категория значимости, либо обоснованно устанавливается, что она не присваивается. Сверить свои системы с перечнем можно в справочнике типовых отраслевых объектов, проверить статус субъекта — в калькуляторе субъекта КИИ, а посчитать категорию — в калькуляторе категорирования; подробный разбор — в статье о субъектах КИИ. Если объект окажется значимым, к модели угроз добавятся требования приказа ФСТЭК России от 25.12.2017 № 239.

Что на каком шаге можно посчитать

Короткая сводка для тех, кто делает модель сам:

• шаг 2, последствия и вред — оценка вреда субъектам;
• шаг 6, отбор угроз — фильтр угроз БДУ и заготовка по типовому решению;
• шаг 8, уровень защищённости — калькулятор уровня защищённости;
• шаг 8, средства защиты — класс и уровень доверия, реестр сертифицированных средств, класс СКЗИ;
• проверка на КИИКритическая информационная инфраструктура — Информационные системы и сети госорганов и организаций ключевых отраслей; режим защиты установлен 187-ФЗ. — субъект КИИ и категорирование.

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

Пять ошибок, которые видно сразу

• Скачанная модель «для медицинской организации». В ней чужие объекты и чужая сеть. Проверяющему достаточно спросить, где в клинике виртуализация, описанная на третьей странице.
• Нарушитель с высокими возможностями везде. Выглядит осторожно, а на деле требует защиты, которой нет, и обесценивает весь документ. Уровень выводится из вида нарушителя и его целей, а не из осторожности автора.
• Перечень угроз без сценариев. Актуальность определяется наличием сценария (пункт 5.3.4). Без него список угроз — просто выписка из банка данных.
• Гостевой Wi-Fi без разделения с рабочей сетью. Человек из очереди оказывается внутри контура. Если сеть разделена — так и напишите в модели; если разделения нет, это отдельный интерфейс, и молчать о нём не стоит.
• «За безопасность отвечает разработчик системы». Оператор персональных данных — клиника. Подрядчик отвечает по договору, а перед законом и перед пациентом отвечает она.

Когда модель пересматривают

Методика требует поддерживать модель угроз в актуальном состоянии в процессе функционирования систем (пункт 2.14). Поводов много, вот самые частые для клиники: появился филиал или второй адрес; медицинская система переехала в облако; открыли телемедицинские консультации; подключили новый обмен с государственной системой; сменился подрядчик поддержки; в банке данных ФСТЭК появились угрозы для используемых технологий; изменились требования нормативных и методических документов или правовой режим обрабатываемой информации; при проверке защищённости нашли сценарий, которого в модели не было; случился инцидент, прошедший не по вашему сценарию. Последние два повода самые ценные: они показывают, чего в модели не хватало.

Коротко

• Модель угроз для клиники делается по общему порядку Методики ФСТЭК России от 05.02.2021. Медицинской спецификой она отличается не порядком, а наполнением.
• Начинают не с угроз, а с последствий: утечка врачебной тайны и подменённая карта — разные беды, и меры из них следуют разные.
• Степень вреда по приказу Роскомнадзора от 27.10.2022 № 178 клинике не выдаётся автоматически: у основания «специальные категории» есть оговорка про случаи, установленные федеральными законами, и её применимость нужно проверить.
• Нарушителей берут тех, чьи цели ведут к вашим последствиям, а уровень возможностей определяют по приложению 8, а не по осторожности: завышение оплачивается деньгами, занижение — ущербом.
• Угрозы отбирают из банка данных ФСТЭК по объектам, интерфейсам и нарушителям, но банк — основной источник, а не единственный, и одной конфиденциальностью ограничиваться нельзя.
• Угроза актуальна, если для неё нашёлся сценарий. Сценарий заодно показывает, где защита обойдётся дешевле всего.
• Из модели выводятся тип угроз и уровень защищённости, состав мер приказа ФСТЭК России от 18.02.2013 № 21 и класс средств защиты. При обоснованном третьем типе угроз клиника с базой меньше 100 000 пациентов получает третий уровень.
• Медицинская организация — юридическое лицо, которому принадлежат системы в сфере здравоохранения, — является субъектом критической информационной инфраструктуры. Информационные системы медицинских организаций входят в перечень типовых отраслевых объектов, поэтому категорирование придётся провести отдельно.