Модель угроз безопасности персональных данных: что это и зачем она сайту
Модель угроз безопасности персональных данных - это документ, в котором оператор описывает, какие данные обрабатывает его информационная система, кто может попытаться получить к ним доступ и какие сценарии атак для этой системы реальны именно сейчас, а не в теории. Без такого анализа невозможно осмысленно выбрать меры защиты: шифрование канала, разграничение прав в CRM, резервное копирование подбираются не по общему списку из интернета, а под конкретный перечень угроз, который заранее выявлен и оценен.
Касается это не только банков и госорганов. Модель угроз обязан иметь любой оператор, который обрабатывает персональные данные с использованием средств автоматизации, - то есть практически любой сайт с формой заявки, интернет-магазин, медицинский центр с электронной записью, образовательная платформа. Как только данные посетителя попадают в базу, таблицу или CRM автоматически, а не переписываются вручную на бумаге, система подпадает под требование иметь такой документ.
Игнорирование обходится дороже, чем кажется. Закон о персональных данных обязывает оператора принимать необходимые правовые, организационные и технические меры для защиты данных от неправомерного доступа, уничтожения, изменения, блокирования, копирования и распространения. Без модели угроз обосновать, что принятые меры действительно необходимые и достаточные, нечем: получается, что антивирус поставили и SSL включили наугад, а не потому что закрыли конкретный сценарий атаки, который был выявлен заранее. При проверке это читается как формальное невыполнение требований к защите персональных данных, и это уже основание для предписания и штрафа.
Дальше - кто именно обязан иметь модель угроз, как поменялась методика ФСТЭК в 2021 году, из каких разделов состоит документ и как выбрать угрозы для обычного сайта с формой обратной связи, а не для банка с сотней серверов.
Кто обязан иметь модель угроз безопасности персональных данных: при чем тут ИСПДн
Чтобы понять, касается ли требование конкретного сайта, нужно разобраться с термином ИСПДн - информационная система персональных данных. Это не сама база данных, а вся связка целиком: персональные данные в базе плюс технические средства и технологии, которые обеспечивают их обработку. Проще говоря - форма на сайте, сервер или облако, где хранятся заявки, CRM, куда они попадают, и люди, у которых есть доступ ко всему этому.
ИСПДн возникает в момент, когда обработка данных автоматизирована хотя бы частично. Если посетитель вводит имя и телефон в форму, и это сохраняется в таблице, почте или CRM без ручной перепечатки на бумажный носитель, - система уже подпадает под определение, вне зависимости от того, сколько заявок приходит в день: одна или сто. Ссылка на маленький размер бизнеса или редкое использование формы не освобождает от обязанности иметь документ, который описывает угрозы для этой системы.
Обязанность разрабатывать модель угроз прямо не сформулирована в самом законе как отдельная статья с таким названием, но вытекает из требования принимать необходимые технические меры защиты и подтверждается практикой ФСТЭК: чтобы выбрать конкретные меры из приказа, которым установлен их состав для информационных систем персональных данных, оператор обязан сначала определить, какие угрозы для его системы актуальны. Без этого шага выбор мер защиты формально ничем не обоснован, а требования к каналам передачи данных и шифрованию, о которых подробно рассказано в статье про SSL и шифрование по требованиям ФСТЭК и ФСБ, применяются в отрыве от реальных рисков конкретного сайта.
На практике из-под требования выпадают только операторы, которые обрабатывают данные исключительно на бумаге, без единой автоматизированной системы, - архив бумажных анкет в сейфе без сканирования и переноса в таблицы. Для сайта, даже самого простого, такой вариант почти никогда не подходит: форма обратной связи, счетчики аналитики и почтовый ящик, куда падают заявки, уже образуют автоматизированную обработку.
Глубина документа при этом разная для разных систем. Сайту-визитке с одной формой имя и телефон нужна модель угроз, но небольшая: несколько страниц с описанием простой архитектуры и коротким перечнем актуальных угроз. Медицинскому центру, который через сайт принимает жалобы пациента и хранит историю обращений, или интернет-магазину с онлайн-оплатой и личным кабинетом нужен документ подробнее - потому что шире набор данных, больше точек, где эти данные проходят, и выше цена ошибки. Закон не требует одинакового объема бумаги от всех, но требует, чтобы документ реально описывал именно ту систему, для которой составлен.
Методика ФСТЭК 2021 года: как изменился подход к оценке угроз
До 2021 года операторы пользовались методикой определения актуальных угроз, которую ФСТЭК утвердила еще в 2008 году. Она строилась на расчете вероятности реализации угрозы и коэффициента опасности через таблицы и формулы: оператор оценивал вероятность в баллах, сверял с таблицей и получал вывод, актуальна угроза или нет. Подход был формальным и не учитывал, что для разных систем одна и та же уязвимость может вести к совершенно разным последствиям.
Новая методика оценки угроз безопасности информации, которую ФСТЭК приняла в 2021 году, сменила логику. Вместо абстрактной вероятности в баллах она предлагает оценивать два параметра: возможность реализации угрозы через конкретный сценарий действий нарушителя и масштаб негативных последствий, к которым эта реализация приведет, - для самого оператора, для субъектов персональных данных и для государства, если система значима на этом уровне. Угроза признается актуальной не потому, что где-то в теории она возможна, а потому что для нее прослеживается реалистичный сценарий атаки, применимый именно к этой информационной системе.
Такой подход требует от оператора не абстрактного заполнения таблицы, а понимания собственной инфраструктуры: какое программное обеспечение используется, куда система подключена извне, какие интеграции подключены, кто имеет доступ к базе. Отсюда и практическая сложность: составить документ по методике 2021 года формально, скопировав чужой шаблон без анализа своей системы, можно, но такой документ не выдержит первой же серьезной проверки и не поможет реально закрыть риски - потому что построен на угрозах чужой системы, а не своей.
Из чего состоит документ: структура модели угроз
Единой обязательной формы модели угроз закон не устанавливает, но на практике сложился набор разделов, без которых документ не выполняет свою функцию:
- общие положения - цель документа, на какую информационную систему он распространяется, на основании какой методики составлен;
- описание информационной системы - состав, где размещена (свой сервер, хостинг, облако), как подключена к интернету, какие данные обрабатывает и в каком объеме, сколько человек имеют доступ;
- перечень возможных нарушителей - внутренние (сотрудники с разным уровнем доступа, включая администраторов) и внешние (посторонние лица, конкуренты, автоматизированные атаки), с оценкой их возможностей и мотивации;
- перечень актуальных угроз с оценкой каждой по методике - источник угрозы, объект воздействия, возможность реализации, вероятные последствия;
- вывод - итоговый список актуальных угроз, на основании которого дальше выбираются конкретные меры защиты;
- порядок пересмотра документа - когда и по каким основаниям модель угроз актуализируется заново.
Последний пункт часто пропускают, а зря. Модель угроз, составленная один раз при запуске сайта и ни разу не пересмотренная, устаревает так же, как политика конфиденциальности с реквизитами компании пятилетней давности. При смене хостинга, добавлении новой формы с более чувствительными полями, подключении нового подрядчика или после инцидента документ нужно пересматривать, а не хранить как памятник моменту запуска сайта.
Банк данных угроз ФСТЭК: как выбрать угрозы для конкретной системы
Основной источник, из которого берут формулировки угроз для модели, - банк данных угроз безопасности информации, который ведет ФСТЭК России и публикует на собственном сайте bdu.fstec.ru. Это реестр, где собраны описания угроз и уязвимостей, актуальных для разных типов информационных систем: каждая угроза в банке имеет свой код вида УБИ и порядковый номер, краткое описание, источник угрозы, объект воздействия и возможные последствия реализации.
Работа с банком данных угроз ФСТЭК устроена так: оператор не придумывает угрозы с нуля, а сопоставляет характеристики своей системы - тип программного обеспечения, наличие подключения к интернету, используемые каналы связи, тип обрабатываемых данных - с описаниями угроз в реестре и отбирает те, что применимы именно к его системе. Часть угроз в банке рассчитана на промышленные системы управления или крупную корпоративную инфраструктуру и заведомо не имеет отношения к сайту на типовой CMS с одной формой заявки, поэтому механически включать в документ весь список из банка не нужно и неверно по сути.
Отдельно в банке данных ведется реестр уязвимостей - конкретных недостатков в распространенном программном обеспечении, включая популярные CMS и плагины. Если сайт работает на системе управления с известными неустраненными уязвимостями, это прямо повышает возможность реализации ряда угроз и должно быть отражено в документе, а не оставлено за скобками с общей формулировкой все обновлено.
На практике формулировка угрозы в документе выглядит примерно так: источник - внешний нарушитель с низким потенциалом; объект воздействия - форма обратной связи на сайте; способ - внедрение вредоносного кода через поле ввода, не прошедшее должную фильтрацию; последствия - несанкционированный доступ к базе заявок. Каждый такой пункт в модели угроз должен опираться не на общие рассуждения о хакерах вообще, а на конкретную запись из банка данных ФСТЭК, адаптированную под особенности сайта.
Актуальные угрозы для типового сайта с формой заявки
Для большинства сайтов услуг набор актуальных угроз похож, потому что похожа сама архитектура: форма на сайте, база или CRM, канал связи между ними, несколько человек с доступом. В таблице - угрозы, которые почти всегда попадают в модель для такой системы, и что снижает их актуальность на практике.
| Угроза | Кто может реализовать | Что снижает актуальность угрозы |
|---|---|---|
| Эксплуатация уязвимости CMS или плагина формы | внешний нарушитель, автоматизированное сканирование сайтов | регулярные обновления движка и плагинов, отказ от заброшенных расширений |
| Перехват данных при передаче без шифрования канала | внешний нарушитель в той же сети, что и посетитель сайта | действующий SSL-сертификат и принудительный редирект на HTTPS |
| Утечка через незащищенную резервную копию базы | внешний нарушитель, получивший доступ к серверу или облаку | шифрование бэкапов, ограничение доступа к папке с резервными копиями |
| Превышение полномочий сотрудником с доступом к CRM | внутренний нарушитель - сотрудник с легитимным, но избыточным доступом | разграничение прав по ролям, журналирование действий в системе |
| Компрометация учетной записи администратора сайта | внешний нарушитель через слабый пароль или фишинг | сложные пароли, двухфакторная аутентификация для админки |
| Утечка через стороннюю интеграцию (виджет чата, сервис рассылок) | внешний нарушитель через уязвимость подрядчика | договор поручения с подрядчиком, проверка его мер защиты |
| Отказ в обслуживании (DDoS), из-за которого форма недоступна | внешний нарушитель, конкурентная атака | защита на уровне хостинга или CDN, план восстановления |
Эта таблица - не готовая модель угроз, а отправная точка для нее. Часть строк для конкретного сайта окажется неактуальной (например, если формы вообще нет и данные собираются только через звонок), а часть придется дополнить - если сайт хранит фотографии клиентов, принимает оплату онлайн или работает с данными о здоровье, набор угроз будет шире того, что уместилось в общую таблицу.
Как составить модель угроз безопасности персональных данных: пошаговый план
Собрать документ можно своими силами, если следовать порядку и не пропускать шаги, которые кажутся необязательными.
- Провести инвентаризацию: какие персональные данные реально собирает сайт, где они хранятся, кто и с каким уровнем доступа может их увидеть - от менеджера с доступом к CRM до хостинг-провайдера с доступом к серверу.
- Определить уровень защищенности системы по установленной правительством классификации - от него зависит, насколько строгими должны быть итоговые меры защиты, и без него сложно оценить масштаб последствий реализации угрозы.
- Составить перечень возможных нарушителей: внутренние - сотрудники разных должностей с разным доступом, внешние - случайные злоумышленники, целевые атаки, недобросовестные подрядчики.
- Отобрать угрозы из банка данных ФСТЭК, применимые к описанной системе, и оценить для каждой возможность реализации и масштаб последствий по действующей методике.
- Сформировать итоговый перечень актуальных угроз - именно тех, что прошли оценку и признаны реальными для этой системы, а не полный список из банка данных без фильтрации.
- На основании перечня выбрать конкретные меры защиты и зафиксировать их отдельно или в том же документе - какая мера закрывает какую угрозу.
- Утвердить документ приказом руководителя, ознакомить с ним ответственных сотрудников под подпись и назначить срок планового пересмотра - обычно не реже раза в год либо при существенном изменении инфраструктуры.
Самая частая ошибка на этом пути - формально пройти все шаги, но составить документ по чужому шаблону, где угрозы и меры подобраны для другой системы. Модель угроз, скачанная целиком с чужого сайта, не станет доказательством того, что оператор реально проанализировал собственные риски: это будет видно уже на этапе описания информационной системы, если оно не совпадает с тем, что есть на самом деле.
Частые ошибки при составлении модели угроз
Кроме копирования чужого шаблона, на практике повторяется еще несколько ошибок:
- документ составляют один раз при запуске сайта и больше не открывают, хотя за это время добавились новые формы, сменился хостинг или подключилась новая CRM;
- в перечень угроз механически переносят весь список из банка данных ФСТЭК без фильтрации по реальной архитектуре системы - получается документ на полсотни страниц, где девять угроз из десяти к сайту не относятся;
- оценивают возможность реализации угрозы на глаз, без привязки к тому, что реально известно об уязвимостях используемого программного обеспечения;
- не учитывают внутреннего нарушителя - модель угроз пишут только про внешние атаки хакеров, забывая, что часть утечек происходит из-за сотрудника с избыточным доступом или бывшего работника, у которого не отозвали пароли;
- не связывают перечень угроз с конкретными мерами защиты - документ описывает риски, но не отвечает на вопрос, что именно сделано, чтобы каждый из них закрыть;
- забывают про подрядчиков и интеграции - виджеты, сервисы рассылок, облачные CRM тоже часть системы и тоже источник угроз, а не нейтральная внешняя инфраструктура.
Каждая из этих ошибок обнаруживается одинаково - при сравнении текста документа с тем, что реально происходит на сайте и в базе данных. Расхождение между описанием и практикой снижает ценность документа до нуля, даже если формально все разделы на месте.
Что будет, если модели угроз нет при проверке
Роскомнадзор при проверке смотрит не столько на сам факт наличия документа с правильным названием, сколько на соответствие между заявленными и фактически реализованными мерами защиты. Полный список того, на что обращает внимание инспектор, разобран в статье про 15 точек контроля на сайте, и отсутствие обоснования выбранных мер - одна из типичных находок. Без модели угроз оператору нечем объяснить, почему выбраны именно эти меры защиты, а не другие, и почему отдельные угрозы вообще не закрыты.
На практике отсутствие документа редко становится единственным и отдельным основанием для штрафа - формулировки в актах обычно шире и звучат как невыполнение требований к защите персональных данных при их обработке в информационных системах. Но именно отсутствие модели угроз чаще всего и есть первопричина: без нее оператор не может доказать, что меры выбраны обоснованно, а не наугад, и инспектор фиксирует это как нарушение с соответствующими последствиями вплоть до предписания устранить его в установленный срок.
Отдельный риск - резервные копии и подрядчики, которые тоже обрабатывают персональные данные оператора. Требования модели угроз распространяются и на них: если бэкапы базы лежат в открытом доступе на личном диске сотрудника, это нарушение даже при формально составленном документе - подробнее о том, где хранить резервные копии можно, а где нельзя, в отдельной статье про хранение резервных копий персональных данных. Похожая логика касается и того, как выглядит подготовка к внеплановой проверке, - в статье про внеплановую проверку РКН собран порядок действий, если уведомление о проверке уже пришло, а документов вроде модели угроз еще нет.
Есть и менее очевидное последствие. Модель угроз - не разовая справка, а рабочий документ: если ее нет, при реальном инциденте, например утечке через незащищенную форму, оператору нечем показать, что риск был известен заранее и меры принимались осознанно. Это влияет на то, как расценивается сама ситуация - как результат добросовестной, но недостаточной защиты или как полное отсутствие какой-либо системной работы с рисками. Разница ощутима и при общении с проверяющим органом, и при последующем разбирательстве.
Практический вывод
Модель угроз безопасности персональных данных - не бумага для галочки и не документ, который один раз пишут и забывают в папке. Это основа, на которой строится весь остальной набор мер защиты сайта: без анализа угроз непонятно, что именно защищать в первую очередь, а что можно оставить на базовом уровне без лишних затрат.
Для сайта с одной формой заявки документ можно составить самостоятельно, если методично пройти шаги: описать систему такой, какая она есть на самом деле, отобрать угрозы из банка данных ФСТЭК, оценить их по действующей методике и на основании этого выбрать меры. Проверить, соответствует ли получившийся результат реальному состоянию сайта, а заодно и остальным требованиям закона, помогает независимый взгляд со стороны - например, через аудит по чек-листу из статьи про аудит сайта на 30 пунктов, где модель угроз - лишь один из проверяемых элементов наряду с формами, согласиями и политикой конфиденциальности.
Если разбираться с методикой ФСТЭК и банком данных угроз самостоятельно некогда или система сложнее типового сайта-визитки - с интеграциями, специальными категориями данных или большой базой контактов, - эту работу можно доверить специалистам, которые составят документ под конкретную инфраструктуру, а не по шаблону из интернета. 152fzpro.ru занимается именно такими задачами: от аудита сайта до подготовки полного пакета документов, включая модель угроз.
