Модель угроз для небольшой компании за один день
Полная модель угроз с формальной методологией занимает недели и нужна не всем. Но у компании любого размера должен быть ответ на вопрос «что мы защищаем и от чего» — иначе меры защиты выбираются по интуиции или по тому, что предлагает очередной подрядчик. Ниже сокращённый, но рабочий способ составить такой документ за один день силами внутренней команды.
Статья опирается на логику направления «Архитектура кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами.
Что должно получиться
| Уровень | Что это значит на практике |
|---|---|
| 2. Гигиенический | Есть документ с перечнем значимых активов и угроз, он используется при выборе мер защиты и пересматривается при изменениях |
Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.
Шаг 1. Перечень активов и точек входа (1–1,5 часа)
Нарисуйте на одном листе (или в любом редакторе схем) компоненты системы и то, как к ним попадают данные: пользователи из интернета, сотрудники по VPN, партнёры через API, подрядчики с прямым доступом к серверам. Для каждого компонента отметьте: что в нём хранится (персональные данные, платёжные реквизиты, исходный код, учётные данные), кто имеет доступ и через какую точку входа. На этом шаге не нужно глубоко детализировать архитектуру — достаточно уровня, на котором видно, где данные пересекают границу доверия (например, из интернета попадают во внутреннюю сеть).
Шаг 2. Перебор сценариев по категориям угроз (2–3 часа)
Для каждой точки входа и значимого актива пройдитесь по шести категориям угроз (сокращённый STRIDE, без строгой методологии — как контрольный список вопросов):
| Категория | Вопрос к каждому компоненту |
|---|---|
| Подмена личности | Может ли кто-то выдать себя за легитимного пользователя или сервис (украденный пароль, подмена токена)? |
| Нарушение целостности | Может ли кто-то изменить данные или код без обнаружения (подмена пакета, модификация конфигурации)? |
| Отказ от авторства | Можно ли отследить, кто совершил действие (есть ли журналирование)? |
| Утечка информации | Может ли посторонний получить доступ к данным (чрезмерные права, незашифрованный канал)? |
| Отказ в обслуживании | Может ли система быть выведена из строя (перегрузка, исчерпание ресурсов)? |
| Повышение привилегий | Может ли пользователь или служба получить больше прав, чем выданы (уязвимость, ошибка конфигурации)? |
Не пытайтесь найти все возможные сценарии — цель за один день — зафиксировать очевидные и наиболее вероятные для вашей системы, а не исчерпывающий список. Полноту даст повторение процесса, а не растягивание одной сессии.
Шаг 3. Оценка и приоритизация (1 час)
Для каждого найденного сценария оцените вероятность и ущерб по простой шкале «низкая / средняя / высокая» и отметьте, есть ли уже мера защиты. Это то же самое, что ведётся в реестре рисков; модель угроз — источник сценариев для него, а не отдельный параллельный процесс.
| Сценарий | Актив | Вероятность | Ущерб | Мера защиты есть? |
|---|---|---|---|---|
| Подбор пароля к админ-панели из интернета | CMS сайта | Высокая | Средний | Нет |
| Утечка через избыточные права сотрудника в базе клиентов | База клиентов | Средняя | Высокий | Частично |
Сценарии с высокой вероятностью и высоким ущербом, где мера защиты отсутствует, становятся входом для плана работ на ближайший квартал.
Что входит в документ
- Схема компонентов и точек входа (из шага 1).
- Таблица сценариев с категорией угрозы, вероятностью, ущербом и статусом меры защиты.
- Дата составления и дата следующего пересмотра.
- Список решений, принятых на основе документа (что добавили в план работ, что сознательно приняли как риск).
Документ не обязан быть длинным: три-четыре страницы с таблицей и схемой работают лучше, чем 40 страниц, которые никто не откроет повторно.
Когда пересматривать
- При появлении нового значимого компонента (новый сервис, новая интеграция с партнёром, новая точка входа извне).
- После значимого инцидента или находки пентеста — проверить, не пропущен ли был сценарий.
- Не реже раза в год как плановый пересмотр, даже если видимых изменений не было: приоритеты бизнеса и состав угроз меняются.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| Сессия растягивается на несколько дней без результата | Пытаетесь охватить все детали архитектуры. Снизьте уровень детализации, вернитесь к нему при следующем пересмотре |
| В списке только технические угрозы | Не учтены сценарии через сотрудников и подрядчиков (социальная инженерия, избыточные права). Добавьте точки входа «через людей» |
| Документ составлен, но не используется | Не связан с планом работ и реестром рисков. Переносите сценарии без защиты в реестр рисков с владельцем и сроком |
| Невозможно оценить вероятность объективно | На первой итерации это нормально: используйте экспертную оценку команды, уточняйте по данным инцидентов и логов в следующих пересмотрах |
Где это в модели зрелости
Материал относится к направлению «Архитектура кибербезопасности» (материалы направления, карта зрелости). Уровень 2 требует, чтобы меры защиты выбирались осознанно, а не случайно: модель угроз даёт основание для такого выбора и связывает архитектуру с реестром рисков и планом работ. Для сетевой части модель угроз логично продолжает сегментация сети.
Как проверить
- Документ существует, в нём есть схема точек входа и таблица сценариев с оценкой.
- Сценарии без меры защиты перенесены в реестр рисков с владельцем и сроком.
- Дата следующего пересмотра назначена и не истекла.
- После последнего значимого изменения архитектуры документ был обновлён.
Источники
- Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
- Microsoft Threat Modeling (STRIDE), общее описание метода: learn.microsoft.com. Используется как общепринятый способ классификации угроз, не как нормативный документ.
