1. Что такое модель угроз
Модель угроз безопасности информации — это документ, в котором зафиксировано, какие именно риски реальны для вашей ИСПДн. Методика ФСТЭК от 5 февраля 2021 года определяет ее как «описание систем и сетей и актуальных угроз безопасности информации» (п. 2.12).
Проще говоря, это документ, который отвечает на три вопроса: что именно вы защищаете, от чего и как, и почему выбранных мер достаточно. На основании модели угроз безопасности подбираются организационные и технические меры, а также средства защиты. Без нее невозможно обосновать ни один пункт бюджета на информационную безопасность.
2. Что закон понимает под угрозой безопасности ПДн
Постановление Правительства от 01.11.2012 № 1119 делит угрозы на три типа. Разница между ними — в источнике уязвимости: есть ли в программном обеспечении скрытые, неописанные функции, которые можно использовать для доступа к данным, или таких функций нет.
Первый тип — угрозы, связанные с наличием недокументированных возможностей в системном программном обеспечении.
Реализация такой угрозы выглядит как ошибка или скрытая функция на уровне операционной системы, драйверов или сервисов, которая приводит к утечке данных без участия прикладного кода. Пример — уязвимость CVE-2025-14551 в установщике Ubuntu Subiquity. При сбое установки система формировала диагностический отчет для отправки разработчикам, но не очищала его от чувствительных данных. В логи попадал пароль от Wi-Fi в открытом виде — его видел любой, кто получал доступ к отчету. Это классический пример НДВ системного уровня: функциональность, не описанная как средство сбора учетных данных, но фактически их раскрывающая.
Второй тип — угрозы, связанные с наличием недокументированных возможностей в прикладном ПО.
Здесь уязвимость скрыта в логике конкретного приложения: CRM, медицинской информационной системы, бухгалтерской программы или мобильного клиента. Показательный случай — уязвимость в приложении Rubetek Home для управления умным домом. Приложение отправляло отладочные файлы через Telegram-бота, и вместе с системной информацией в них уходили ФИО, телефон, email, полный адрес объекта и Refresh-токены для авторизации в аккаунте. Формально это была функция логирования, а фактически — канал утечки персональных данных, встроенный в прикладной код.
В российских ИСПДн аналогичный механизм часто связан с 1С. В 2024 году при атаке на сеть фитнес-клубов World Class в открытый доступ попала резервная копия базы 1С с данными 2,2 млн клиентов и сотрудников, включая ФИО, адреса, телефоны и банковские карты. А в 2026 году частную клинику в Москве оштрафовали за утечку из МИС «Медиалог» и 1С:ЗУП, где оказались результаты анализов и сведения о назначениях. В обоих случаях уязвимость или ошибка конфигурации прикладного слоя открывала доступ к массиву ПДн.
Третий тип — угрозы, не связанные с недокументированными возможностями в системном и прикладном ПО.
Здесь скрытых функций в коде нет. Утечка происходит через человека, организационный пробел в защите или внешний канал: фишинг, недобросовестный сотрудник, подрядчик с избыточным доступом.
Примеров в российской практике больше всего. В 2026 году специалист офиса продаж сотового оператора в Череповце сфотографировал экран служебного компьютера и через мессенджер передал данные 31 абонента — включая паспортные данные и баланс лицевого счета. В Прикамье сотрудник страховой компании втайне от работодателя получил доступ к базе клиентов из финансовой заинтересованности. Отдельная категория — фишинг: в 2026 году жительница Сыктывкара лишилась данных через поддельное приложение «Ленты», после чего на ее имя попытались оформить кредиты.
В этих кейсах ни системное, ни прикладное ПО не содержало скрытых возможностей. Угроза реализовалась через легальный доступ, которым злоупотребили, или через обман пользователя. Именно поэтому для 3-го типа ключевые меры — организационные: разграничение прав, контроль действий персонала, обучение и проверка подрядчиков.
Если вы обосновали в документе, что НДВ в системном и прикладном ПО отсутствуют или нейтрализованы, вы фиксируете 3-й тип угроз. Это позволяет установить более низкий уровень защищенности (УЗ-3 или УЗ-4) и не внедрять избыточные меры. Ошибка в определении типа — например, запись «НДВ нет» без анализа используемого ПО — приводит к тому, что реальные риски остаются без мер, а проверяющие увидят разницу между моделью и инфраструктурой.
3. Кому нужна модель угроз
Модель угроз персональных данных обязательна для любого оператора, который обрабатывает данные в информационной системе. Неважно, коммерческая это компания или госорган. Если у вас есть база клиентов в CRM, кадровый учет в 1С или форма обратной связи на сайте — вы оператор, и у вас есть ИСПДн.
Отдельно модель угроз требуется для:
государственных информационных систем (ГИС) — здесь с 1 марта 2026 года действует приказ ФСТЭК № 117 от 11.04.2025, заменивший прежний приказ ФСТЭК № 17;
значимых объектов критической информационной структуры (КИИ) — для КИИ действует собственный набор требований (приказ ФСТЭК № 239);
систем, обрабатывающих сведения ограниченного доступа.
Для коммерческих ИСПДн согласовывать модель угроз ИСПДн с регуляторами не нужно — ее утверждает руководитель организации-оператора.
4. Что такое ИСПДн
Информационная система персональных данных (ИСПДн) — это совокупность данных в базе, а также информационных технологий и технических средств, которые позволяют обрабатывать эти данные с использованием средств автоматизации или без них.
На практике это может быть:
CRM или ERP-система с данными клиентов;
бухгалтерская программа с кадровыми сведениями;
сайт с формами заявок и личным кабинетом;
мобильное приложение, собирающее данные пользователей;
облачный сервис, где хранятся резюме или договоры с физическими лицами.
Для каждой системы модель угроз безопасности составляется отдельно. Архитектура, состав данных и сценарии атак у CRM и у бухгалтерии различаются, поэтому и содержание документа во всех случаях будет разным.
5. На основании каких документов разрабатывается модель угроз
Основной методический документ — Методика оценки угроз безопасности информации, утвержденная ФСТЭК 5 февраля 2021 года. Именно она задает логику: как описывать систему, как определять актуальность угроз, как оформлять результат.
Дополнительно используются:
Постановление Правительства № 1119 — устанавливает требования к защите ПДн и уровни защищенности (УЗ-1 – УЗ-4);
Приказ ФСТЭК № 21 от 18.02.2013 — действует и определяет состав и содержание мер по уровням защищенности;
Базовая модель угроз безопасности ПДн (утверждена ФСТЭК 15.02.2008) — используется как справочник для понимания типовых угроз, хотя старая методика расчета актуальности больше не применяется;
Банк данных угроз безопасности информации ФСТЭК (БДУ) — официальный реестр с идентификаторами и описаниями угроз, на который опираются при составлении перечня.
Важно учитывать проект нового приказа. Летом 2026 года ФСТЭК опубликовала проект, который должен заменить приказ № 21 и ввести риск-ориентированный подход с оценкой «уровня зрелости защиты». Пока он не вступил в силу, применять его как действующий нормативный акт нельзя. Но заложенные в нем принципы — привязка мер к реальным угрозам, а не к формальному уровню защищенности — стоит учитывать уже сейчас, чтобы модель угроз не пришлось переписывать после изменения требований.
6. Почему нельзя скачать готовую модель угроз
В шаблоне из интернета не будет учтена ваша инфраструктура, и это одна из основных причин, почему его не стоит использовать. В нем будут другие системы, другие каналы связи и другие уязвимости. Формально документ будет, но при проверке инспектор увидит, что он не отражает реальные процессы. Это создает ложное чувство безопасности и повышает риск утечки — а вместе с ней и штрафа.
С 2025 года за утечки персональных данных введены оборотные штрафы, и их размер зависит от масштаба последствий. Сумма может достигать 500 млн рублей. Поэтому модель угроз безопасности информации должна описывать именно вашу систему: какие серверы, где они находятся, кто имеет доступ, какие каналы связи используются, есть ли облако или подрядчики. Универсального документа здесь быть не может, его нужно разрабатывать индивидуально.
7. Из каких этапов состоит разработка модели угроз
1) Описание системы и ее границ
Сначала нужно зафиксировать, что именно защищается. Это не просто перечень программ, а описание системы как объекта защиты: состав и категории обрабатываемых ПДн, бизнес-процессы, архитектура, точки подключения к интернету, используемое системное и прикладное ПО, уже внедренные средства защиты, а также группы пользователей и их полномочия.
Отдельно фиксируются внешние взаимодействия: какие каналы связи используются, передаются ли данные в облако или подрядчикам, есть ли интеграции с другими системами. Если компания работает на инфраструктуре ЦОД или облачного провайдера, в модели отражаются условия договора с ним — это прямо предусмотрено Методикой. Границы системы определяют, что войдет в анализ, а что останется за рамками.
2) Определение негативных последствий
На этом шаге описывается, что произойдет, если конфиденциальность, целостность или доступность данных нарушатся. Методика требует оценивать последствия для субъектов ПДн, для оператора и для третьих лиц.
Последствия утечки ПДн по Методике ФСТЭК всегда включают ущерб физическому лицу: нарушение конфиденциальности, риск травли в сети, разглашение сведений. Для оператора это дополнительно штраф по ст. 13.11 КоАП, потеря клиентов и репутационные потери. Для кадровых данных — нарушение трудовых прав и претензии работников; для медицинских сведений — вред здоровью.
3) Определение объектов воздействия
Объекты воздействия — это информационные ресурсы и компоненты системы, неправомерный доступ к которым или воздействие на которые может привести к негативным последствиям. Методика выделяет несколько групп таких объектов:
информация (данные): сами ПДн, конфигурационные файлы, данные телеметрии, журналы событий безопасности;
программно-аппаратные средства: серверы, автоматизированные рабочие места, сетевое оборудование, носители информации;
каналы связи и интерфейсы: точки подключения к интернету, каналы передачи данных между подразделениями, API для интеграций;
учетные записи и средства аутентификации: логины, пароли, ключи доступа, сертификаты;
помещения, где размещено оборудование.
Для каждого объекта указывается, какой вид воздействия на него возможен: копирование, модификация, уничтожение, блокирование. Совокупность объектов и их интерфейсов определяет границы анализа.
4) Определение источников угроз
Источники угроз — это те, кто или что может реализовать угрозу. Методика делит их на несколько категорий: внешние нарушители (хакеры, конкуренты, криминальные группы), внутренние нарушители (сотрудники, подрядчики, администраторы), а также технические сбои и природные явления.
Для каждого источника оцениваются возможности — набор средств и навыков, которым он располагает. Уровни возможностей варьируются от минимальных (скрипт-кидди, использующий готовые инструменты) до высоких (специализированные группы с собственными разработками). От этого зависит, какие способы реализации угроз будут рассматриваться как реальные. Если в системе нет удаленного доступа, угрозы перехвата трафика извне можно исключить — но только после того, как это будет обосновано в модели.
5) Составление перечня актуальных угроз
Это ядро модели. Из Банка данных угроз ФСТЭК (БДУ) отбираются не все записи, а только те, которые реализуемы в вашей системе и приводят к существенным негативным последствиям.
Критерий актуальности по Методике 2021 года: угроза признается актуальной, если существует хотя бы один сценарий ее реализации, учитывающий конкретного нарушителя, его возможности, объект воздействия и способ реализации. Сценарий — это пошаговое описание того, как именно угроза может быть реализована: через какую уязвимость, с какого интерфейса, с какими последствиями для субъектов и оператора.
Если для угрозы нет подходящего сценария — она признается неактуальной и в перечень не включается. Каждая актуальная угроза потребует меры защиты, а каждая неактуальная — обоснования, почему она снята.
Представим магазин на собственном веб-движке. База клиентов хранит ФИО, телефоны, адреса доставки, историю заказов и хэши паролей. Данные банковских карт не хранятся — платежи идут через внешний шлюз. Сайт доступен из интернета, админка — только через VPN. Сотрудники работают с заказами через браузер.
Угроза (БДУ ФСТЭК) | Сценарий реализации | Вывод |
Угроза внедрения кода или данных (SQL-инъекция) | Внешний нарушитель с базовыми навыками находит форму поиска по каталогу, не защищенную от подстановки SQL-кода. Через нее получает доступ к таблице customers и выгружает базу клиентов. Последствия: утечка ПДн, штраф по ст. 13.11 КоАП, потеря доверия покупателей. | Актуальна. Есть нарушитель, уязвимость (непараметризованные запросы), интерфейс (форма поиска) и существенные последствия. |
Угроза перехвата акустической информации | Нарушитель пытается перехватить речевые сигналы в помещении, где оператор принимает заказы по телефону. | Неактуальна. В системе нет голосового ввода ПДн и воспроизведения данных акустическими средствами. Сценарий не реализуется. |
Угроза несанкционированного доступа к акустической информации | Записи разговоров хранятся в информационной системе. Нарушитель получает доступ к архиву через учетную запись с избыточными правами или через уязвимость в веб-интерфейсе и копирует аудиофайлы. | Актуальна, если доступ к архиву записей не разграничен, нет шифрования файлов и журналирования операций. Меры: разграничение прав, шифрование хранилища, аудит доступа. |
Угроза перехвата трафика между клиентом и сервером | Нарушитель в публичной Wi-Fi-сети пытается перехватить данные, которые покупатель отправляет при оформлении заказа. | Неактуальна при HTTPS. Канал защищен шифрованием, перехват содержимого невозможен. Если HTTPS не внедрен — угроза становится актуальной, и это первый разрыв, который нужно закрыть. |
Угроза хищения средств хранения информации (УБИ.160) | Сотрудник колл-центра копирует аудиофайлы на внешний носитель и выносит их из офиса. | Актуальна, если не ограничен физический доступ к рабочим станциям и не ведется учет носителей. Меры: контроль носителей, запрет использования внешних накопителей, организационные меры. |
6) Выбор мер защиты
Для каждой актуальной угрозы подбирается мера, которая ее нейтрализует или снижает риск. Меры делятся на организационные (приказы, разграничение прав, обучение), технические (межсетевые экраны, антивирусы, шифрование, системы обнаружения вторжений) и программные (обновления, контроль уязвимостей).
Состав мер привязан к уровню защищенности ИСПДн и требованиям приказа ФСТЭК № 21: для УЗ-1 набор шире, для УЗ-4 — минимальный. Меры выбираются под конкретные угрозы. Если угроза признана актуальной, а мера для нее не предусмотрена, проверяющий обязательно это зафиксирует.
7) Оформление документа
Модель угроз утверждается руководителем организации-оператора. Тип угроз в модели и уровень защищенности в акте классификации не могут расходиться. Пересматривается модель при изменении архитектуры, появлении новых угроз или изменении законодательства — но не реже, чем этого требуют регуляторы.
8. Где брать перечень угроз
Основной источник — Банк данных угроз безопасности информации ФСТЭК (bdu.fstec.ru). Это официальный реестр, где каждая угроза имеет уникальный идентификатор, описание и возможные последствия. В нем несколько сотен записей — от ошибок пользователей до целевых атак с вредоносным кодом.
При разработке модели угроз не нужно включать весь банк. Отбор идет по трем критериям, закрепленным в Методике 2021 года:
угроза может быть реализована с учетом архитектуры и защиты вашей системы;
в используемом ПО есть соответствующая уязвимость;
последствия от реализации угрозы существенны для бизнеса или субъектов данных.
Дополнительно можно использовать отраслевые перечни угроз, если они утверждены для вашей сферы. Но проверять их актуальность нужно каждый раз — ведомственные акты обновляются.
9. Что должно быть в модели угроз
Раздел 1. Общие положения. Назначение документа, нормативная база, оператор, ответственные лица.
Раздел 2. Описание системы как объекта защиты. Категории и объем ПДн, уровень защищенности, бизнес-процессы, архитектура, интерфейсы, группы пользователей, внешние взаимодействия, облако или ЦОД.
Раздел 3. Возможные негативные последствия. Виды ущерба для субъектов и оператора.
Раздел 4. Возможные объекты воздействия. Базы, серверы, АРМ, каналы, учетные записи.
Раздел 5. Источники угроз. Нарушители, их цели и возможности.
Раздел 6. Способы реализации угроз. Интерфейсы и каналы, через которые возможно воздействие.
Раздел 7. Актуальные угрозы. Перечень сценариев с выводом об актуальности и типе угроз.
Раздел 8. Меры защиты. Для каждой актуальной угрозы — организационные и технические меры, которые ее нейтрализуют.
Модель может быть краткой для небольшой ИСПДн и объемной для распределенной системы с облаком и подрядчиками. Главное — она должна соответствовать реальной инфраструктуре.
Разработка модели угроз
Защита информации и подготовка к проверкам
10. Как модель угроз связана с уровнем защищенности ИСПДн
Уровень защищенности (УЗ-1 – УЗ-4) определяется сочетанием трех параметров: типа угроз, категории обрабатываемых данных и количества субъектов.
Модель угроз фиксирует тип угроз. Если вы обосновали, что недокументированных возможностей в системном и прикладном ПО нет, это 3-й тип. Если есть — 2-й или 1-й. От этого зависит, какой уровень защищенности установить и какой объем мер потребуется.
Для большинства коммерческих компаний с CRM, 1С и сайтом типична комбинация «3-й тип угроз и иные ПДн» — это УЗ-3 или УЗ-4. Но вывод нужно обосновать в модели, а не выбрать «на всякий случай» высокий уровень: каждый уровень требует разных затрат.
11. Типичные ошибки
Ошибка 1. Безответственный подход. Скачанный шаблон или документ, который не отражает реальную архитектуру. Проверяющие смотрят не на наличие документа, а на связь между угрозами и мерами.
Ошибка 2. Перечень угроз без анализа. Включение всех угроз из БДУ «для полноты». Это делает документ нерабочим: если угроза признана актуальной, под нее должна быть мера, а если меры нет — это нарушение.
Ошибка 3. Модель без связи с уровнем защищенности. Тип угроз в модели и уровень защищенности в акте классификации расходятся. Это внутреннее противоречие, которое проверяющий заметит.
Ошибка 4. Отсутствие актуализации. Модель написана один раз и не пересматривается. Обновлять ее нужно при изменении архитектуры, появлении новых угроз или изменении законодательства.
Ошибка 5. Разработка без лицензии. Если модель делает внешняя организация по договору, у нее должна быть лицензия ФСТЭК на техническую защиту конфиденциальной информации. Без лицензии документ может быть поставлен под сомнение.
Ошибка 6. Игнорирование проекта нового приказа. Модель, которая закрывает только текущие требования № 21 и не учитывает переход к риск-ориентированному подходу, может потребовать переработки в ближайшее время. Заложите в документ логику «угроза — мера», а не просто привязку к уровням защищенности.
Реклама: АО «Консалтинг онлайн», ИНН: 2310203967, erid: 2W5zFHwDf2r
