Модель угроз: как её строить по требованиям ФСТЭК и для реальной защиты

Расскажем, как с помощью модели угроз определить, что защищать, от кого и зачем. Объясним, как ее строить по требованиям ФСТЭК, как применять, чтобы ИБ была обоснованной, эффективной и понятной.

Компания собирается внедрять СЗИ, но не знает, с чего начать: подрядчик предлагает «всё и сразу», руководство требует обоснований затрат, а регуляторы ждут документы по информационной безопасности. Расскажем, как навести порядок, выявить реальные риски, расставить приоритеты и подготовить обоснованный план защиты.

Что такое модель угроз?

Когда говорят о защите информации, первой приходит в голову техника или ПО: антивирусы, межсетевые экраны, СЗИ. Однако начинать нужно не с оборудования, а с понимания — от чего именно вы защищаетесь. Таким образом, вы сразу выстраиваете защиту под требования информационной безопасности.

Определение и назначение модели угроз в ИБ

Это документ, который описывает, кто и как может навредить информационной системе. Поясняет, какие инциденты актуальны для конкретной организации, на какие уязвимости они опираются.

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

Роль модели в системе защиты информации

Это фундамент всей системы информационной безопасности. На неё опираются при выборе технических и организационных мер защиты, при проектировании архитектуры ИБ, при обосновании закупок.

Без неё невозможно построить защиту, которая будет соответствовать требованиям регуляторов, работать в реальных условиях. На ее основе создают политики безопасности, планы реагирования на инциденты, техзадания на внедрение средств защиты.

Регуляторы, в том числе ФСТЭК, требуют сначала строить модель угроз, а затем подбирать СЗИ — обоснованно, под реальные сценарии.

Чем отличается модель угроз от оценки рисков и ТЗИ

Техническая защита информации — ТЗИ и модель угроз  связаны, но задачи у них разные:

• Модель описывает потенциальные действия нарушителей, уязвимости, на которые те могут опереться. Отвечает на вопрос: что и как могут попытаться сломать?
• Оценка рисков идёт дальше: учитывает вероятность реализации рисков и последствия для бизнеса. Её цель — приоритизировать, на что стоит тратить силы и ресурсы в первую очередь.
• ТЗИ — это конкретный список мер, которые нужно выполнить. Модель угроз — это обоснование, почему эти меры вообще нужны. Сначала описывается угроза, потом определяется мера, которая её закрывает.

Требования ФСТЭК и других регуляторов к моделям угроз

ФСТЭК предъявляет конкретные требования к построению документа. Для государственных информационных систем, КИИ, ГИС и ИСПДн разработаны отдельные методички. Основной регламент — это Методика по выявлению актуальных угроз безопасности информации (ФСТЭК России, утв. в 2021 году).

Согласно методике модель должна включать:

1. Описание информационной системы, включая состав ресурсов, архитектуру.
2. Перечень предполагаемых нарушителей (в том числе внутренних).
3. Описание возможных сценариев реализации инцидентов.
4. Связь между уязвимостями и мерами защиты.
5. Указание на классы угроз в соответствии с базой УБИ ФСТЭК.
6. Если речь идёт об ИСПДн — привязку к уровням защищённости.

Для объектов КИИ действует другая логика: сначала проводится категорирование, а потом уже выстраивается модель. Требования к ней изложены в приказе ФСТЭК №235.

Важно: у других регуляторов, например, Банка России или Роскомнадзора, свои подходы к моделированию. Но при работе с государственными и критическими системами ориентироваться нужно именно на ФСТЭК: их модель считается базовой, наиболее проработанной.

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

Обязательные случаи по закону: ГИС, КИИ, ПДн и другие

Есть ситуации, когда регламент нужен по закону. Без него невозможно пройти согласование или защитить систему в рамках требований.

Вот основные случаи, когда модель обязательна:

• Государственные информационные системы (ГИС) — в соответствии с приказом ФСТЭК №17 и методикой по определению актуальных угроз входит в комплект обязательной документации для аттестации.
• Критическая информационная инфраструктура (КИИ) — необходимо разработать после категорирования объекта, как указано в приказе ФСТЭК №235.  Учитывает типовые сценарии атак, включая действия иностранных разведслужб.
• Информационные системы персональных данных (ИСПДн) — необходима для систем с 1–3 уровнем защищённости. Это прописано в приказе ФСТЭК №21.

Для ИСПДн важно сразу определить, где хранится информация ограниченного доступа и кто к ней имеет доступ.

• Автоматизированные системы управления технологическими процессами (АСУ ТП) — тоже обязательна, если система связана с КИИ или используется на объектах повышенной опасности.
• Информационные системы в оборонной, банковской или транспортной сферах — для них действуют отдельные регуляторные акты, но логика та же: если система важна — без модели не обойтись.

Во всех этих случаях отсутствие документа — нарушение. За это предусмотрены штрафы, риск приостановки работы системы, особенно при проверке регулятора или в рамках госзакупок.

Добровольное моделирование — выгоды для бизнеса

Даже если закон не требует регламентировать риски, бизнесу она часто нужна. Особенно там, где ценится предсказуемость, прозрачность, экономия ресурсов.

Модель поможет в следующих случаях:

1. При запуске нового сервиса или IT-системы, чтобы понять, какие риски нужно учесть заранее, до покупки оборудования и настройки защиты.
2. При переходе в облако помогает разобраться, какие угрозы остаются на стороне клиента, а какие — у провайдера.
3. В крупных проектах цифровизации, когда требуется объяснить ИТ-дирекции, где тонкие места, какие меры реально нужны.
4. После инцидентов, чтобы понять, почему защита не сработала, какие риски не были учтены.

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

Модель как основа проектирования ИБ-системы

Когда проектируется система защиты, приходится выбирать, что защищать, от кого, каким способом.

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

1. Помогает определить приоритеты — какие данные критичны, какие каналы самые уязвимые, где нужен контроль доступа.
2. Позволяет связать уязвимости и риски с конкретными средствами защиты, а значит, избежать дублирования и ненужных затрат.
3. Обосновывает архитектуру системы ИБ: от логики разграничения доступа до параметров журналирования.

Это значит, что ИБ-система будет продуманной структурой, с чёткой логикой, понятными зонами ответственности.

Обоснование затрат на безопасность перед руководством

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

В ней можно показать:

1. Кто именно может атаковать компанию.
2. Какие уязвимости для этого используются.
3. Какие потери понесёт бизнес, если опасность реализуется.
4. Какие меры конкретно перекрывают эти риски, сколько это стоит.

Таким образом, разговор не о «покупке firewall», а о предотвращении, например, потери клиентской базы или остановке производства.

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

Из чего состоит модель угроз безопасности данных

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

Объекты защиты: информация, ресурсы, инфраструктура

Первый шаг — определить, что нужно защищать. В модели это называют объектами защиты.

Сюда входят:

1. Информация — коммерческая тайна, персональные данные, сведения о клиентах, данные производственного учёта, документы. То есть всё, что нельзя потерять, подделать или раскрыть без последствий.
2. Ресурсы — серверы, рабочие станции, системы хранения, средства резервного копирования, сетевое оборудование. То, через что проходит и обрабатывается важная информация.
3. Инфраструктура — каналы связи, доменная структура, VPN, сегменты сети, облачные компоненты, прочие элементы, обеспечивающие работу систем.

Нужно перечислить и описать все объекты. Так вы не будете распыляться, а получите четкое осознание, где находится ядро ценности, вокруг которого должна строиться защита.

Угрозы: внутренние и внешние

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

По происхождению их делят на такие типы:

• Внешние — атаки со стороны киберпреступников, конкурентов, хактивистов, иностранных спецслужб. Это фишинг, DDoS, внедрение вредоносного ПО, взлом снаружи. Если модель угроз включает сценарии DDoS, важно заранее изучить специфику DDoS-программ (ботов и стрессеров) и типичные паттерны атак.
• Внутренние — действия сотрудников (осознанные или случайные), подрядчиков, партнёров с доступом к внутренним системам. Это утечки через мессенджеры, копирование данных на флешки, удаление информации, саботаж.

ФСТЭК в своей методике предлагает базу типовых угроз (УБИ), где каждой присвоен код, дано описание. В документе следует указать, какие из этих них актуальны именно для вашей системы.

Нарушители: уровни доступа, мотивация

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

Нарушителей делят на группы:

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

Для каждой группы указываются:

• уровень доступа: гость, пользователь, администратор
• наличие мотивации: корысть, месть, шантаж, халатность
• уровень подготовки: от неспециалиста до продвинутой АРТ-группы

Это помогает оценить, насколько реалистично выполнение атак.

Каналы и векторы реализации

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

К основным векторным каналам относятся:

• Электронная почта, мессенджеры — основная платформа для фишинга.
• Веб-интерфейсы — могут содержать уязвимости, через которые происходит взлом.
• Съёмные носители — частый способ внести вирус или скопировать данные.
• Внутренние сети — если нет сегментации, нарушитель может быстро перемещаться по инфраструктуре.
• Облачные сервисы — особенно при некорректной настройке прав и шифрования.

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

Уязвимости, их классификация и примеры

Угрозы реализуются через уязвимости — слабые места в системе. Это может быть недоработка в настройке, устаревшее ПО или неотключённые функции. Многие уязвимости возникают из-за пробелов в программной безопасности (AppSec) — это особенно критично для систем с коротким циклом разработки и частыми обновлениями.

В модели их классифицируют по типам:

• Технические — открытые порты, уязвимости ПО (по базам типа CVE), слабые пароли.
• Процессные — отсутствие контроля доступа, слабая система учёта, неактуальные резервные копии.
• Человеческий фактор — низкий уровень осведомлённости пользователей, отсутствие обучения, игнорирование ИБ-политик.

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

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

Узнайте, как оценить и закрыть реальные уязвимости в инфраструктуре.

Последствия: для бизнеса, репутации, пользователей

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

Последствия описываются по направлениям:

1. Финансовые потери — штрафы, простой в работе, восстановление инфраструктуры.
2. Репутационные риски — публикация данных, недоверие со стороны клиентов или партнёров.
3. Юридические последствия — претензии надзорных органов, судебные иски, нарушение условий контрактов.
4. Ущерб пользователям — утечка персональных данных, сбой в обслуживании, нарушение SLA.

Описывайте последствия не абстрактно, а применительно к объектам защиты. Например: утечка проектной документации приведёт к потере тендера и убыткам, а недоступность CRM — к остановке отдела продаж.

Этапы построения документа

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

Определение целей моделирования

Сначала важно понять и сформулировать, зачем нужна модель. Цели влияют на глубину ее проработки и состав.

Это могут быть:

• Подготовка к аттестации или сертификации по требованиям ФСТЭК.
• Анализ уязвимостей для новой информационной системы.
• Разработка политики безопасности и стандартов.
• Оценка рисков для принятия управленческих решений.

Четко сформулированные цели позволят эффективно распределять ресурсы и обеспечить максимальную актуальность модели.

Описание ИС: границы, архитектура, взаимодействие

Следующий шаг — подробно описать информационную систему (ИС), для которой строится модель.

Здесь нужно определить:

1. Границы системы — какие компоненты и данные входят в систему, какие находятся вне ее
2. Архитектуру — основные узлы, серверы, приложения, базы данных.
3. Взаимодействия — как компоненты связаны между собой, с внешними системами, пользователями.

Такое описание поможет понять, где могут проявиться угрозы,  какие каналы атаки актуальны.

Идентификация угроз по базам ФСТЭК/ФСБ/ГОСТ

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

• База актуальных угроз ФСТЭК содержит описание типовых сценариев атак.
• Методики ФСБ — с учётом особенностей государственных объектов.
• ГОСТ Р 57580.1-2017 — стандарты, рекомендации по информационной безопасности.

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

Классификация и ранжирование нарушителей

Нарушители делятся на категории по уровню доступа и мотивации.

Рекомендуется:

• Определить группы нарушителей: внешние, внутренние, случайные.
• Оценить возможности каждого: технический уровень, доступ к ресурсам.
• Оценить мотивацию: корысть, вредительство, халатность.

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

Формирование сценариев реализации угроз

На этом этапе абстрактные риски превращаются в понятные и проверяемые ситуации. Сценарий описывает, как конкретный нарушитель может реализовать конкретную угрозу в условиях вашей системы.

Чтобы сценарий был полезен, в нём обязательно указываются:

1. Тип нарушителя — например, внешнее лицо без доступа, сотрудник с правами администратора, подрядчик с временным доступом.
2. Его возможности — какие ресурсы или инструменты он может использовать, какие слабые места знает.
3. Конкретная уязвимость — уязвимый веб-интерфейс, неконтролируемые съёмные носители, слабые пароли, незакрытый порт.
4. Канал или вектор атаки — через Интернет, через сотрудника, по почте, с флешки, по VPN.
5. Цель действий — доступ к данным, блокировка системы, обход контроля.
6. Последствия для организации — утечка персональных данных, остановка сервиса, штраф регулятора, репутационный ущерб.

Эти сценарии помогают просто выявить риски, подготовить защиту на уровне конкретных шагов нарушителя. По ним легче проверять систему на устойчивость, разрабатывать технические меры, обосновывать внедрение СЗИ.

Оценка вероятности и ущерба

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

Для оценки вероятности учитываются:

• Техническая осуществимость — насколько сложно реализовать угрозу на практике, есть ли у нарушителя нужные инструменты, доступ.
• Мотивация и ресурсность нарушителя — готов ли он тратить время и усилия, насколько велик интерес к атаке именно на вашу систему.
• Текущие меры защиты — какие механизмы уже внедрены, насколько они снижают вероятность успеха.

Ущерб анализируется не только в рублях. Обязательно рассматриваются:

• Прямые потери — например, простой системы, восстановление после атаки, штрафы.
• Репутационные риски — особенно важны для банков, онлайн-сервисов, госорганов.
• Правовые последствия — если произошла утечка ПДн или нарушение требований регуляторов.

Подход даст объективную картину: что надо защищать в первую очередь, какие риски можно временно оставить за бортом — до следующих этапов развития ИБ.

Формирование документа и визуальной схемы

На финальном этапе все собранные данные оформляются в понятный рабочий документ. Его можно использовать как основу для защиты, обоснования закупок, при аттестации.

Какие разделы надо включить:

1. Цель и задачи моделирования — чтобы было понятно, зачем всё это делалось, какие решения принимались на основе документа.
2. Описание системы, объектов защиты с понятными границами, данными, инфраструктурой.
3. Сценарии угроз — кто, как, через что, зачем может навредить.
4. Оценку ущерба, его вероятность — чтобы понять, что критично, а что пока нет.
5. Выводы, рекомендации — какие меры нужно принять, какие уязвимости закрыть в первую очередь.

Дополнительно создаётся наглядная схема — диаграмма с объектами, рисками, каналами, нарушителями. Её удобно использовать на совещаниях, при защите проекта или для объяснения руководству сути рисков.

Подходы и методики в российском контексте

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

Методика ФСТЭК: структура, нюансы, типовые ошибки

Методика ФСТЭК – это фундамент для построения моделей угроз в российских организациях. Она подробно описывает, как правильно определять типовые риски для конкретной инфраструктуры, как уменьшить вероятность их наступления. Основной документ – «Методические рекомендации по моделированию угроз безопасности информации» утверждены ФСТЭК РФ.

Основные шаги и структура:

1. Идентификация активов. Сначала вы определяете, какие данные или системы требуют защиты. Это могут быть базы клиентов, финансовые отчёты или промышленное оборудование.
2. Моделирование возможных источников опасности. ФСТЭК предлагает учитывать как внешние (хакеры, конкуренты, кибератаки), так и внутренние (недобросовестные сотрудники, ошибки эксплуатации) источники.
3. Классификация. На основе анализа определяется, какие из возможных рисков наиболее опасны: кража данных, саботаж, вредоносные программы, другое.
4. Планирование мер защиты. После анализа угроз надо сформировать план по их уменьшению. Здесь можно описать технические решения, обучение персонала, другие мероприятия.

Ошибки, которые встречаются чаще всего:

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

Методика ФСТЭК помогает определить минимум требований, но, насколько детальной и эффективной будет готовый документ, зависит от организации.

ГОСТ Р 57580 и специфика финсектора

Стандарт ГОСТ Р 57580-2017 разработан специально для финансовых организаций. Банки, страховщики, инвестиционные компании работают с огромными массивами чувствительных данных, поэтому защита информации здесь — задача первостепенной важности.

Что отличает подход по ГОСТ Р 57580:

1. Фокус на клиентских данных. Главная цель – предотвратить утечки персональной и коммерческой информации клиентов.
2. Учёт угроз внутреннего характера. Финансовый сектор традиционно подвержен инсайдерским рискам (например, недобросовестные сотрудники).
3. Сложные модели рисков. Например, при модификации или отказе IT-сервисов могут пострадать взаимосвязанные процессы: от кассовых операций до обработки онлайн-платежей.
4. Четкая последовательность этапов, начиная с анализа рисков и заканчивая контролем реализации мероприятий по обеспечению информационной безопасности.

Игнорирование требований ГОСТ Р 57580 может привести к штрафу со стороны регуляторов, к серьёзному ущербу репутации.

Пример. При внедрении модели угроз банк отдельно рассмотрел риск DDOS-атак на платёжные системы, а также сценарий утечек из баз данных, вызванных ошибками сотрудников. Было принято решение установить дополнительный уровень мониторинга активности, ограничить возможность копирования массивных данных.

Пример применения STRIDE и DREAD в России

Мировые методики идеально подходят для анализа угроз информационных систем.

STRIDE помогает определить их типы по шести основным категориям:

• Spoofing (Подделка идентичности): риски, связанные с подделкой личности пользователя или ресурса.
• Tampering (Изменение данных): нарушения целостности данных, включая возможность их умышленного искажения.
• Repudiation (Отказ от обязательств): ситуации, когда пользователи отрицают выполнение определенных действий.
• Information disclosure (Раскрытие информации): нарушения конфиденциальности, подразумевающая несанкционированный доступ к данным.
• Denial of service (Отказ в обслуживании): атаки, направленные на снижение доступности ресурсов путем перегрузки серверов.
• Escalation of privilege (Эскалация привилегий): инциденты, возникающие вследствие возможности повышения уровня полномочий злоумышленником.

DREAD — инструмент количественной оценки уровня риска каждой выявленной угрозы. Основан на пяти ключевых параметрах::

• Damage potential (Потенциальный ущерб): степень возможного ущерба в результате успешной атаки.
• Reproducibility (Воспроизводимость): насколько легко повторить атаку повторно.
• Exploitability (Эксплуатируемость): простота осуществления атаки.
• Affected users (Количество пострадавших пользователей): масштаб потенциального воздействия угрозы.
• Discoverability (Обнаруживаемость): вероятность обнаружения уязвимости атакующим.

Пример:

Компания, работающая с промышленными системами, решила провести моделирование рисков. Сначала специалисты определили потенциальные угрозы с помощью STRIDE:

• Возможна фальсификация данных в каналах обмена между датчиками и серверами.
• Есть риск нарушения конфиденциальности, если злоумышленник перехватит команды управления.

Затем провели анализ по DREAD, чтобы понять, какие из этих рисков наиболее критичны. Например, риск фальсификации оценили высоко, так как подмена данных в производственном цикле может привести к аварии. Реализация атаки требует лишь доступа к сегменту сети (легко достижимо).

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

Когда применять зарубежные методики, как их адаптировать

Зарубежные практики, такие как NIST Cybersecurity Framework (США) или ISO/IEC 27001, эффективны в контексте крупных международных компаний или при работе с зарубежными партнёрами. Их внедрение в России требует учёта местной специфики.

Когда применение иностранных практик целесообразно:

1. Международная деятельность: работа с международными партнерами, поставщиками услуг или участие в глобальных цепочках поставок.
2. Высокотехнологичные отрасли: разработки программного обеспечения, облачные сервисы, IoT-решения.
3. Области недостаточной регламентации: новые технологии вроде AI, блокчейн, Big Data, где национальные стандарты ещё находятся в стадии формирования.

Советы по адаптации:

• Совмещайте стандарты. Например, используйте NIST для оценки рисков, но сопровождайте его анализом по ГОСТ Р в части локальных угроз.
• Убедитесь, что применяемый международный стандарт соответствует российскому законодательству, защищает интересы вашей компании.
• Учитесь на опыте. Начните тестировать выбранные инструменты постепенно, сначала применяя их в рамках небольшого проекта или отдельного направления деятельности.

Пример:

IT-компания при развертывании облачного решения использовала:

• ISO 27001 для создания политики доступа и защиты данных.
• Требования приказа ФСТЭК №239 для адаптации своей системы к российским реалиям.

Используя международные стандарты вместе с российскими регламентами, вы сможете создать сбалансированную систему защиты информации, соответствующую современным мировым тенденциям, соблюдающую российские правовые нормы

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

При разработке информационных систем

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

Что нужно учесть:

1. Определить защищаемые активы, понять, какие данные и функции ИС критичны. Например, база персональных данных клиентов, сервер платёжных операций, система управления производственным оборудованием.
2. Учесть сценарии угроз. Шаблонными решениями здесь не обойтись. Например, если система разрабатывается для промышленных объектов, предусмотрите сценарий взлома интерфейсов управления.
3. Продумать функциональность защиты в архитектуре приложения. От аутентификации пользователей до контроля взаимодействия с внешними системами: безопасные механизмы должны быть встроены в архитектуру.

Пример. Разработка CRM-системы для финансовой организации. На основе модели угроз была встроена многофакторная аутентификация, ограничение одновременной авторизации на нескольких устройствах, шифрование данных при передаче. Таким образом, удалось на старте минимизировать риски взлома и утечки.

При построении системы защиты информации (СЗИ)

Базовая модель угроз — необходимый инструмент при выборе защитных решений. Не имеет значения — межсетевые экраны, система контроля и управления доступом (СКУД), криптографическая защита (СКЗИ) или антивирусное ПО. Выстраивая ее, вы понимаете, какие угрозы нужно закрыть в первую очередь.

Как это выглядит на практике:

• Межсетевые экраны. Регламент покажет, на каких уровнях необходимо разделять трафик: нужен контроль доступа между внутренними сегментами сети или достаточно защитить только периметр. Например, в банке отдельный сервер с финансовыми транзакциями точно требует сегментации и независимого мониторинга.
• СКЗИ (средства криптозащиты информации). Если из модели следует, что угрозы перехвата данных при передаче наиболее вероятны, то понадобится шифрование всех каналов связи, в том числе VPN между подразделениями.
• Мониторинг и реагирование. На этапе построения СЗИ важно понять, какие действия системы защиты должны быть автоматизированы. Например, автоматическая изоляция узлов при подозрении на компрометацию.

Пример. При защите системы управления складами (WMS) выявили критическую угрозу — подключение злоумышленника к Wi-Fi в зоне погрузки. Решения: использование отдельного защищённого сегмента сети, внедрение строгой авторизации для всех мобильных терминалов.

Почему готовые модели угроз облегчают работу с регуляторами

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

Как применяется регламент безопасности:

1. Документальное обоснование. Модель угроз персональных данных — это официальный документ, подтверждающий, что организация понимает свои риски и планирует меры защиты осознанно. Например, при проверках Роскомнадзора по защите ПНд (№152-ФЗ), ее наличие показывает, что компания осознала существующие риски, приняла необходимые защитные меры.
2. Скорость устранения замечаний. Если в документе уже описаны угрозы и в зависимости от них сформированы меры защиты, будет проще сослаться на неё для устранения претензий регуляторов.
3. Выравнивание требований. Многие компании сталкиваются с одновременным действием разных правовых норм и отраслевых правил, например: нормы ФСТЭК (объект КИИ) и требования ЦБ (финансовый сектор). Модель угроз облегчает интеграцию разных наборов требований, показывая, что одни и те же меры защищают организацию сразу от нескольких видов киберрисков.

Пример. Перед проверкой ЦБ банк заранее актуализировал модель угроз, включив сценарии утечек через отдалённую работу сотрудников. Это позволило показать регулятору, что риски удалённой работы учтены, а меры защиты соответствуют стандартам.

При аудите и улучшении текущей системы ИБ

Актуальная модель помогает не только при создании или проверке систем, но и при оптимизации существующей ИБ-инфраструктуры. Это актуально для тех организаций, где изменения в бизнесе или технологиях происходят регулярно.

Этапы применения:

1. Ревизия рисков. Угрозы, которые раньше были ключевыми, со временем могут стать менее актуальными. Например: компания перешла на облачные технологии, риск локальных атак на серверы снизился. На первый план выходят вопросы облачной безопасности.
2. Выявление слабых мест. С помощью модели можно проверить эффективность текущих мер защиты. Например, документ показывает, что уязвимость системы централизованного управления остаётся незакрытой — могут потребоваться дополнительные решения.
3. Обоснование новых инвестиций. Модель угроз может стать инструментом для обоснования перед руководством необходимости закупки новых решений. Она ответит на вопросы, какое оборудование актуально, какие риски оно покроет.

Пример. IT-компания провела аудит на основе ранее созданной модели. В ходе оценки глобального отказа процессов из-за перебоя в электропитании выяснилось, что не все системы имеют резервный источник. Это стало основанием для закупки и внедрения дополнительных источников бесперебойного питания.

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

Частые ошибки при построении

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

Копипаст с типовых шаблонов без анализа

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

Почему это плохо:

• Шаблонные документы рассчитаны на усреднённые риски, которые не совпадают с реалиями вашей компании. Например, угрозы, характерные для индустрии банковского сектора, нерелевантны для производственного предприятия.
• Специфические угрозы (например, связанные с уникальной инфраструктурой или бизнес-процессами) не будут учтены.

Проверьте, соответствуют ли типовые шаблоны вашей инфраструктуре и бизнесу. Используйте их как базу для проработки деталей, а не как готовое решение.

Преувеличение или занижение уровня угроз

Неправильная оценка уровня риска часто приводит к перекосу в системе защиты. Можно потратить бюджет и ресурсы на малозначительные угрозы, игнорируя при этом реальные риски.

Типичные примеры:

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

Используйте объективную оценку рисков с использованием аналитических методик (например, DREAD), чтобы определить наиболее критичные и вероятные угрозы.

Игнорирование нестандартных каналов утечки

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

Типичные упущения:

• Физические носители. Например, съёмный USB-накопитель, который сотрудник может потерять вместе с важной информацией.
• Угрозы в облаке. Если инфраструктура вынесена в облачные технологии, то риски, связанные с неправильными правами доступа к данным, недооцениваются.
• Новые технологии. Например, IoT-устройства, подключённые к корпоративной сети, могут стать слабым звеном в защите.

При моделировании учитывайте всю инфраструктуру, включая физические устройства, сотрудников, подрядчиков, SaaS-сервисы и IoT.

Отсутствие связки с реальными мерами защиты

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

Типичные ошибки:

• Угрозы есть, но меры защиты не определены: например, указали риск утечки через персонал, но не прописали контроль доступа к данным и обучение сотрудников.
• Меры не соответствуют заявленной опасности: угроза внешнего взлома прописана как критическая, а фактически покупается лишь базовый антивирус.

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

Отсутствие актуализации при изменении ИС

Информационные системы постоянно развиваются: добавляются новые сервисы, модернизируется софт, меняются бизнес-процессы. Соответственно, и модель угроз  безопасности информации должна обновляться, учитывая эти изменения:

• Компания внедрила облачные технологии, но в документе не учли новые риски, связанные с доступом третьих сторон к инфраструктуре.
• Модель использует устаревшую информацию: упоминает технологии, которые давно заменены на более современные.

Пересматривайте модель угроз при любом изменении инфраструктуры или после внедрения новых технологий. Проводите ревизию хотя бы раз в год, даже если крупных обновлений не происходило. Регулярно обновляйте документ, чтобы он не стал бесполезной формальностью.

Текущие тренды и вызовы

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

Рост атак на КИИ и госсектор

Одна из основных целей злоумышленников — КИИ. Атаки на такие объекты наносят огромный вред как конкретной компании, так и целым регионам, странам и обществу.

Какие тенденции доминируют:

• Целенаправленные кибератаки. Хакерские группы атакуют объекты энергетики, здравоохранения, телекоммуникаций, транспорта, используя сложные сценарии, такие как APT-атаки (Advanced Persistent Threat).
• Шпионаж и саботаж. Мы видим рост атак, ориентированных не только на кражу данных, но и на вывод из строя ключевых систем.

Учитывайте специфические риски инфраструктур, включая особенности физических систем (например, SCADA) или объектов IoT, которые интегрируются в КИИ. Примеры: отключение энергосетей или манипуляция в системах транспортного управления.

Интеграция моделей угроз в DevSecOps

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

Какой тренд формируется:

• Моделирование начинает включаться в ранние этапы разработки — ещё до написания первых строк кода. Это своевременно выявляет потенциальные векторы атак на архитектурные решения.
• Используются автоматизированные инструменты для анализа киберугроз и уязвимостей по мере сборки и тестирования новых модулей. Например, интеграция сценариев STRIDE в pipeline CI/CD.

Работая в рамках DevSecOps, важно уметь быстро и гибко адаптировать модель угроз под изменения кода. Это потребует автоматизации процессов моделирования, активного использования инструментов, совместимых с подходом DevOps.

Моделирование угроз для облаков и гибридных ИТ

Переход на облачные платформы или гибридную инфраструктуру создаёт новые вызовы для моделирования угроз. Данные, ранее сосредоточенные в локальной инфраструктуре, теперь распределяются между облаком и офисными средами, что расширяет возможные векторы атак.

Основные тренды:

• Атаки на CSP (Cloud Service Provider). Угроза того, что злоумышленник атакует саму платформу, где хранятся ваши данные (например, «Яндекс Облако»).
• Ошибка конфигурации. Ошибки в настройках доступов к облачным сервисам приводят к тому, что конфиденциальные данные могут стать доступными в публичной среде.
• Гибридная сложность. Инфраструктуры, совмещающие локальные и облачные ресурсы, требуют моделей, которые учитывают взаимосвязь между этими средами.

Необходимо учитывать сценарии угроз на уровне инфраструктуры и сервисов. Например, сценарий компрометации токенов доступа или манипуляции через API.

Сценарные модели и имитация атак (Threat Simulation)

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

Развивающиеся практики:

• Threat Simulation Tools. Такие инструменты, как MITRE ATT&CK, помогают моделировать сценарии атак в реальной инфраструктуре. Можно проверить, насколько грамотно выстроена модель угроз.
• Красные команды (Red Teaming). Профессиональные группы моделируют действия злоумышленников для проверки текущей системы защиты.
• Сценарные тренировки. Используются гипотетические сценарии — например, как система защиты среагирует на внутренний инсайд или утечку данных через мобильные устройства.

Для построения сценарных моделей от вас потребуются знания о типичных для отрасли векторах атак, о наиболее вероятных действиях злоумышленников.

Как начать работу

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

Где взять шаблоны и рекомендации

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

Источники шаблонов и материалов:

• Методика ФСТЭК РФ. Если ваша организация подчинена требованиям российского законодательства (например, №187-ФЗ о КИИ), методические рекомендации ФСТЭК станут базовым документом. Они детализируют этапы, дают примеры подходов к моделированию.
• ГОСТы. Например, ГОСТ Р 57580–2017 для финансового сектора или ГОСТ Р ИСО/МЭК 27005 дают полезные принципы анализа рисков, которые можно использовать при работе.
• Международные стандарты. Если вы работаете с зарубежными партнёрами или применяете международные лучшие практики, обратите внимание на NIST SP 800-30 или OWASP Threat Modeling Framework. Они популярны в экосистеме DevSecOps.
• Открытые базы знаний. Инструменты вроде MITRE ATT&CK предоставляют библиотеку готовых сценариев атак, систематизированные знания о реальных векторах угроз. Используя их, вы быстрее идентифицируете актуальные риски, подготовите адекватные меры защиты.

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

Как собрать команду: ИБ, ИТ, юристы, бизнес

Моделирование угроз — это комплексная задача, она требует участия разных специалистов. Ошибочно полагать, что этим могут заниматься только ИБ-специалисты.

Ключевые участники процесса:

1. Инженеры и администраторы ИТ.  Знают все тонкости инфраструктуры: от сетевой архитектуры до баз данных.
2. Специалисты по информационной безопасности. Анализируют угрозы, ведут документацию, планируют меры защиты.
3. Юристы и комплаенс-менеджеры. Их задача — убедиться, что документ покрывает не только технологические аспекты, но и соответствует законодательству (№152-ФЗ, №187-ФЗ, требования ЦБ, GDPR при международных проектах).
4. Представители бизнеса. Помогают приоритизировать активы, прогнозировать реальные последствия атак: что критично для бизнеса, а что допустимо.

Объедините специалистов в одну команду. Локальная угроза для IT может восприниматься как стратегическая проблема для бизнеса и наоборот.

Как организовать процесс как часть SDLC

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

Где включать моделирование:

1. Этап планирования. Анализируются архитектура, потенциальные векторы атак. На основе этого формируются необходимые меры безопасности.
2. Этап разработки. Используются инструменты для выявления уязвимостей, например Checkmarx или Threat Modeling Tool от Microsoft.
3. Этап тестирования. Проводятся имитации сценариев атак (Threat Simulation), чтобы проверить документ на практике.
4. Этап эксплуатации. Внедрение мониторинга угроз, чтобы актуализировать модель по мере изменения реальных рисков.

Пример. При разработке мобильного приложения для ритейлеров на этапе планирования учли попытки перехвата клиентских данных через незашифрованные соединения между приложением и сервером. Для устранения угрозы встроили шифрование API уже на ранних этапах.

Что проверяют регуляторы, как подготовиться

Регуляторы пристально следят за тем, как компании понимают и управляют своими рисками. В России ключевые регуляторы по ИБ — это ФСТЭК, Роскомнадзор, Банк России. Каждый из них предъявляет свои требования, но есть общие принципы подготовки, которые помогут вам «сдать экзамен» с минимальным стрессом.

Чего ждут регуляторы:

• Наличие документа. Регуляторы ФСТЭК и ЦБ требуют документально оформленную модель угроз, в которой будет чётко показано, какие риски учтены, чем они закрыты.
• Защита персональных данных. Если ваша компания обрабатывает данные граждан (например, списки клиентов, работников), модель должна показать, какие меры приняты для соблюдения №152-ФЗ.
• Актуальность мер защиты. Проверки включают анализ соответствия модели текущему состоянию инфраструктуры и законодательным требованиям. Например, прописаны ли меры для защиты КИИ, если ваша компания относится к критической инфраструктуре.
• Соответствие международным стандартам. Если вы работаете с зарубежными партнёрами, регуляторы могут дополнительно заинтересоваться соответствием требованиям ISO 27001, PCI DSS и т.д.

Как подготовиться:

• Регулярно актуализируйте регламент: он должна отражать текущее состояние вашей инфраструктуры.
• Проведите внутренние аудиты перед проверками. Это поможет вовремя выявить слабые места и устранить их.
• Подготовьте набор доказательств, что меры из модели внедрены на практике: например, логи работы антивируса или отчёты SIEM-систем.

Работа с моделью — это не одномоментный проект, а постоянный цикл улучшений. Начните с изучения шаблонов, документов, соберите команду, организуйте процесс как часть регулярной работы по ИТ или SDLC. Если сделать всё грамотно, вы будете чувствовать себя уверенно перед любыми проверками или возникающими рисками.

Главное

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

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

Роль регуляторов (ФСТЭК, Роскомнадзор, ЦБ) в требованиях к модели угроз.
Для многих компаний разработка модели обязательна по закону (например, для КИИ, ИСПДн). Невыполнение требований чревато штрафами и приостановкой бизнеса.

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

Технические подходы: интеграция в SDLC, использование шаблонов и стандартов.  Моделирование угроз на ранних этапах разработки (DevSecOps) предотвращает проблемы еще до запуска. Методики STRIDE, DREAD, NIST и ГОСТ, дают проверенные способы анализа. Совмещение стандартов (например, российских и международных) помогает закрывать как локальные, так и глобальные риски.

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

Тренды: кибератаки на КИИ, облака, гибридные среды, развитие Threat Simulation. Современные киберугрозы требуют более глубокого анализа, автоматизации в DevSecOps, имитаций атак для проверки текущей модели.
Следите за новыми трендами, чтобы безопасность компании не остановилась на старых сценариях.

Начало работы: готовые шаблоны, команда, интеграция в бизнес-процессы.
Модель угроз системы безопасности можно начать строить на основе методологии ФСТЭК, ГОСТ или международных стандартов, подключив к процессу экспертов из ИТ, ИБ, юристов и бизнес.

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