Модели угроз информационной безопасности — для чего нужны и почему без них не обойтись бизнесу

Тема моделей угроз информационной безопасности сегодня актуальна как никогда. По данным «Лаборатории Касперского», только в 2025 году количество целевых атак на российские компании выросло на 38% по сравнению с предыдущим годом. Сводный индекс цифровых угроз (по оценке Positive Technologies) показывает, что более 70% атак имеют финансовую или политическую мотивацию, а средний ущерб от одной успешной кибератаки для крупной организации превышает 50 млн рублей.

Рост числа скомпрометированных персональных данных (только за I квартал 2026 года в открытом доступе оказалось более 120 млн записей о россиянах) заставляет регуляторов ужесточать требования, а бизнес — пересматривать подходы к защите.

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

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

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

Разработка модели угроз в РФ регламентируется:

• Приказом ФСТЭК России № 117 от 20.04.2023 «Об утверждении требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах»,
• Приказом ФСТЭК России № 21 от 18.02.2013 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных»,
• Приказом ФСТЭК России № 31 от 14.03.2014 (для автоматизированных систем управления производственными и технологическими процессами),
• Приказом ФСТЭК России № 239 от 25.12.2017 (для значимых объектов критической информационной инфраструктуры),
• Методикой оценки угроз безопасности информации ФСТЭК России (утв. 05.02.2021), которая является методологической основой для разработки.

Перечень угроз — это каталог (справочник) возможных угроз, не привязанный к конкретной системе. Его ведёт, например, ФСТЭК в Банке данных угроз (bdu.fstec.ru).

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

Виды моделей угроз по уровню детализации:

• Обобщённая (типовая) описывает угрозы на уровне класса систем, без привязки к конкретной архитектуре, и используется как отправная точка или для однотипных систем.
• Частная разрабатывается для конкретной организации с учётом её инфраструктуры, отрасли и типа обрабатываемых данных — это наиболее распространённый вид на практике.
• Детальная включает глубокий анализ векторов атак, сценариев, потоков данных и используется для объектов КИИ, ГИС высокого класса защищённости, при подготовке к аттестации систем.

Модель угроз обязательна для следующих типов систем:

• государственные информационные системы любого класса (прямое требование Приказа № 117) (ЕГИСЗ, ГИС ЖКХ, региональные порталы ГосУслуг)
• информационные системы персональных данных (Приказ № 21), (CRM с клиентскими базами, HR-системы, медицинские ИС)
• значимые объекты КИИ (Приказ № 239) (АСУ ТП на производстве, биллинговые системы операторов связи)
• системы на объектах ТЭК и финансовые организации согласно отраслевым требованиям ЦБ и Минэнерго.

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

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

Чаще всего за модель угроз ошибочно принимают политику информационной безопасности — это ошибка. Политика информационной безопасности лишь регламент поведения, а не анализ угроз. Список установленных средств защиты (антивирус, файрвол, DLP) — это описание мер защиты. Инструкция пользователя по работе с ПК вообще не относится к моделированию угроз.

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

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

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

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

Моделирование угроз позволяет решить следующие практические задачи:

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

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

Модель угроз НЕ решает следующие задачи:

• не является планом реагирования на инциденты — описывает угрозы, но не содержит инструкций «что делать, когда атака уже идёт»;
• не заменяет анализ уязвимостей (пентест) — описывает теоретические векторы, но не проверяет их реализуемость технически; она не гарантирует соответствия требованиям ИБ автоматически — это лишь один из документов системы защиты.

С этим кажется, работает HR или служба безопасности. На деле именно эта классификация и есть основа модели угроз: прежде чем выбирать инструменты защиты, нужно понять, от кого и от чего конкретно защищаться. От обиженного сотрудника с доступом к базе клиентов, от увольняющегося администратора в последние дни перед уходом, от случайной ошибки удалённого работника с личного ноутбука. Модель угроз отвечает именно на этот вопрос: «от чего конкретно мы защищаемся и почему это актуально именно для нашей системы» — и логически предшествует и политике ИБ, и выбору СЗИ.

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

Скрытые риски третьих лиц. По оценкам российских ИБ-аналитиков, от 20 до 30% утечек в B2B-сегменте связаны с третьими сторонами: подрядчиками, аутсорсинговыми командами, вендорами с удалённым доступом. Этот вектор необходимо описывать в модели отдельно — с указанием, к каким системам имеет доступ подрядчик, какие механизмы контроля применяются (выделенные учётные записи, журналирование, ограничение прав). Это один из самых недооценённых векторов в моделях угроз среднего бизнеса.

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

Отличие внутренней угрозы в наличии у нарушителя легитимных учётных данных и физического и/или логического доступа к системе. Сотрудник с правомерным доступом — потенциальный внутренний нарушитель. Человек снаружи периметра — внешний. Подрядчик с VPN-доступом находится в «серой зоне» и в большинстве методик защиты рассматривается отдельно.

Основные виды внешних угроз

1. Фишинг — рассылка от имени легитимных организаций или коллег с целью украсть учётные данные или развернуть вредоносное ПО. Один из самых массовых и эффективных каналов проникновения.
2. DDoS-атака — массированная отправка запросов, приводящая к отказу в обслуживании. Критична для систем, чья доступность критически важна: сайты, порталы, внешние сервисы.
3. Эксплуатация уязвимостей — использование незакрытых ошибок в программном коде для несанкционированного доступа. Риск растёт пропорционально сложности и возрасту системы.
4. Атака на цепочку поставок — внедрение вредоносных компонентов через обновления, зависимости или оборудование вендора. Особенно опасна для систем, активно использующих сторонний код и облачные сервисы.
5. Атака «человек посередине» — перехват или подмена трафика между узлами. Актуальна при отсутствии шифрования в каналах связи, особенно в распределённых и удалённых сценариях.
6. Подбор паролей и использование утечек — автоматический перебор паролей либо вход по скомпрометированным учётным данным из публичных баз. Прямо зависит от качества парольной политики и наличия двухфакторной аутентификации.
7. Вредоносное ПО — программы-вымогатели, трояны, кейлоггеры, шпионские модули. Заносятся через вложения, ссылки, съёмные носители и часто служат начальной стадией более сложных атак.
8. Веб-атаки (SQL-инъекции и аналоги) — передача вредоносных конструкций через поля ввода веб-приложений с целью доступа к базе данных. Актуально для любых систем с веб-интерфейсом.
9. Социальная инженерия — прямое манипулирование персоналом для получения доступа или информации. Один из наиболее результативных методов, поскольку обходит технические средства защиты.
10. Продвинутая устойчивая угроза (APT) — длительная, многоэтапная, целевая атака, как правило, со стороны государственных или высококвалифицированных криминальных групп. Включает разведку, проникновение, закрепление, латеральное перемещение и эксфильтрацию данных. Для организаций без критической инфраструктуры, госконтрактов или стратегически значимых данных включение APT в модель угроз избыточно. Исключение — предприятия ОПК, финансового сектора и телеком-операторы.
11. Немотивированная внешняя угроза — атака, не нацеленная на конкретную организацию. Например, бот-сеть сканирует диапазоны IP-адресов в поиске открытых RDP-портов и использует уязвимости протокола, подбирает пароли. Жертвой становятся не по причине выбора, а в силу наличия уязвимого места. Именно такие угрозы составляют большинство реальных инцидентов в малом и среднем бизнесе.

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

Классификации внутренних нарушителей.

По мотивации:

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

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

По статистике Verizon DBIR и российских отчётов, около 60–70% инцидентов, связанных с внутренними нарушителями, обусловлены неумышленными действиями. Умышленные составляют 30–40%, но они, как правило, наносят гораздо больший ущерб.

По уровню доступа, согласно методике ФСТЭК, пользователи распределяются следующим образом:

• пользователь без особых привилегий;
• пользователь с привилегированным доступом (администратор ОС, БД);
• разработчик или сотрудник вендора с доступом к коду;
• лицо с физическим доступом к аппаратным компонентам.

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

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

Внутренние угрозы, о которых не задумываются. 

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

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

Виды ущерба от реализации угроз:

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

В мае 2024 года атака остановила работу СДЭК— логистического оператора, который обрабатывает около 300 тысяч отправлений в день. Сутки не принимались и не отправлялись заказы, не работали сайт и приложение. По оценкам экспертов, ущерб мог составить от 300 млн до 1 млрд рублей. Это прямое сочетание операционного ущерба в виде простоя ключевого процесса с финансовыми потерями и репутационными издержками, особенно чувствительными для B2C-сервиса, зависящего от доверия клиентов.

В июле 2024 года атака нарушила работу ИТ-инфраструктуры розничной сети «Винлаб»: отключились онлайн-продажи и часть розничных точек. Ущерб от простоя оценивался примерно в 1 млрд рублей — здесь операционная остановка напрямую и почти без искажений конвертировалась в прямые финансовые потери сопоставимого масштаба.

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

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

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

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

По структуре типовой документ включает следующие разделы.

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

Рекомендуемый минимальный объём реально работающей модели угроз для небольшой компании (до 100 сотрудников, ИСПДн 3-го уровня защищённости) составляет от 30 до 50 страниц. Меньший объём, скорее всего, свидетельствует о поверхностном анализе. Для крупного предприятия (ГИС 1-го класса, КИИ) — 130–200 и более страниц с приложениями. Объём не является самоцелью, но недостаточный объём сигнализирует о неполноте анализа.

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

Пошаговая инструкция разработки модели угроз:

1. Определить объект оценки и границы моделирования;
2. Собрать исходные данные об инфраструктуре, данных и пользователях;
3. Составить перечень активов (информационных и инфраструктурных - данные, серверы, приложения, каналы связи, носители информации) и оценить их ценность;
4. Сформировать перечень потенциальных угроз из Банка данных угроз ФСТЭК (bdu.fstec.ru) с учётом специфики организации;
5. Описать нарушителей (типы, возможности, мотивацию) применительно к данной организации;
6. Оценить актуальность каждой угрозы — проверить наличие нарушителя и условий реализации;
7. Описать последствия, зафиксировать остаточные риски, согласовать с руководством и утвердить документ.

Шаг, который занимает больше всего времени (35–50% всего времени проекта), — сбор исходных данных. Проблема в том, что информация часто разрозненна, документация устаревшая или отсутствует, а нужные данные приходится собирать по крупицам из разных подразделений. Если инфраструктура плохо задокументирована, этот этап может затянуться на недели.

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

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

Сколько времени требуется на подготовку модели угроз. В общем случае разработка модели угроз занимает от нескольких недель до нескольких месяцев. Срок зависит от двух факторов: размера и сложности системы, а также качества исходных данных. В небольшой компании с хорошей документацией можно уложиться в 2–3 недели. В средней или крупной — процесс обычно занимает 2–4 месяца. Основное время уходит не на саму аналитику, а на сбор информации и согласования: уточнение инфраструктуры с ИТ, статуса данных с юристами и допустимого уровня ущерба с руководством. Если система подлежит аттестации, добавляется ещё одна итерация с аттестационным органом. Чем хуже исходные данные — тем дольше будет идти проект.

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

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

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

Когда нужен эксперт по ИБ. Если в штате нет ИБ-специалиста, внешний консультант необходим для компаний численностью уже от 50–80 сотрудников с обязательными требованиями по работе с ИБ (ИСПДн, ГИС). Для более мелких компаний можно обойтись готовыми методическими материалами ФСТЭК и типовыми шаблонами, если риски невысоки. Для КИИ и ГИС 1-го класса внешний эксперт обязателен независимо от размера штата, поскольку аттестация предполагает серьёзную документальную и техническую экспертизу.

Внедрение модели угроз включает:

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

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

Модель угроз должна пересматриваться и актуализироваться не реже 1 раза в 3 года в плановом порядке, а также при любых значимых изменениях системы или ситуации с угрозами. Для ГИС 1-го класса и значимых объектов КИИ — фактически при каждом изменении архитектуры.

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

Ответственный за поддержание модели в актуальном состоянии — руководитель службы ИБ или назначенный сотрудник; если службы нет, ответственность возлагается на системного администратора с обязательным оформлением приказом, а не «по умолчанию».

По нашим оценкам, среди компаний, которые разрабатывали модель угроз самостоятельно или формально, «для галочки», реально внедряют её меры защиты лишь около 30%. Среди компаний, которые привлекали внешнего консультанта и разрабатывали модель как рабочий инструмент, этот показатель значительно выше — до 75%. Главный барьер — отсутствие плана обработки рисков как следующего шага: модель написали, положили в папку, но никто не начал реализовывать описанные меры защиты.

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