“Оценка угроз — это механизм перевода абстрактных списков опасностей в конкретные, осязаемые риски для вашей системы прямо сейчас. Это основа для любых осмысленных защитных мер, а не бюрократический ритуал.”
Цель оценки угроз
Главный смысл процесса — трансформировать общий перечень теоретических опасностей в конкретный список угроз, которые могут быть реализованы в вашей информационной системе в текущих условиях. Актуальность определяется не по абстрактной классификации, а по возможности технической реализации в вашей архитектуре с учётом её известных уязвимостей, настроек и контекста работы. Без этого перехода от общего к частному защита строится на домыслах и часто пропускает реальные бреши.
Ключевой принцип
Работа должна быть систематической и цикличной. Оценка, проведённая единожды при внедрении системы, устаревает через несколько месяцев. Инфраструктура меняется, появляются новые дыры в ПО, меняются тактики нападающих. Оценка угроз — это не проект с финальной датой, а регулярный процесс, встроенный в жизненный цикл системы и её изменений.
Что именно делается в рамках оценки
- Определяется, какой именно ущерб может принести реализация угрозы: прямой финансовый, репутационный, сбой критически важного процесса.
- Проводится инвентаризация того, что нужно защищать: не просто «серверы», а конкретные системы, потоки данных, прикладные функции.
- Формируются профили возможных нарушителей — от невнимательного сотрудника до целенаправленной внешней группы, с разными уровнями мотивации, ресурсов и стартовой позиции.
- Анализируются не названия угроз из справочника, а конкретные технические пути их реализации именно в вашей среде.
- Оценивается реализуемость каждой угрозы с учётом текущей конфигурации и внешних факторов.
- Разрабатываются детализированные сценарии атак, описывающие шаг за шагом, как нарушитель может достичь цели.
Что нужно знать перед началом
Качественный анализ невозможен без контекста. Исходные данные образуют многослойную основу для работы.
| Категория данных | Ключевые источники | Роль в оценке |
|---|---|---|
| Нормативные требования | Банк данных угроз ФСТЭК России, отраслевые типовые модели угроз | Формирование обязательного к рассмотрению базового набора. Игнорирование угроз из БДУ создаёт правовые риски. |
| Тактики и методы атак | Фреймворки MITRE ATT&CK, CAPEC, списки вроде OWASP Top 10 | Понимание современных, реально применяемых методов, выходящее за рамки формальных перечней. |
| Документация системы | Техническое задание, архитектурные схемы, руководства по эксплуатации | Понимание принципов работы, компонентов и сценариев использования защищаемой системы. |
| Внешняя инфраструктура | Договоры с ЦОД, облачными провайдерами (SLA) | Определение границ ответственности и учёт угроз из общей или управляемой инфраструктуры. |
| Нормативная база | 152-ФЗ, приказы ФСТЭК, отраслевые стандарты | Формальные требования к итоговой модели угроз и выбранным мерам защиты. |
| Бизнес-контекст | Описания ключевых процессов, технологические карты, политики | Связь ИТ-активов и угроз с реальным ущербом для бизнеса для правильного расставления приоритетов. |
Когда проводить оценку: проектирование
На этапе проектирования анализ строится на предполагаемой архитектуре. Это позволяет изначально закладывать принципы безопасного дизайна. Результаты напрямую влияют на ТЗ для разработчиков, обосновывают выбор конкретных средств защиты и их настройку. Здесь можно относительно дёшево предотвратить уязвимости, исправление которых на поздних стадиях обходится на порядок дороже.
Когда проводить оценку: эксплуатация
Здесь анализ проводится для реально работающей системы. Цель — проверить эффективность уже внедрённых мер против актуальных угроз и выявить новые риски, возникшие после ввода системы в эксплуатацию. Например, из-за накопления неустранённых уязвимостей, изменений в сетевой топологии, новых интеграций или смены бизнес-процессов.
Кто должен участвовать
Это всегда командная работа, требующая разных экспертиз. За координацию обычно отвечает подразделение информационной безопасности, но без активного участия специалистов предметной области оценка становится оторванной от реальности.
- ИТ-специалисты (сисадмины, сетевые инженеры) знают реальную конфигурацию систем и их слабые места, о которых нет в документации.
- Разработчики и архитекторы понимают внутреннюю логику приложений, потоки данных и скрытые взаимозависимости компонентов.
- Владельцы бизнес-процессов могут адекватно оценить реальный операционный и финансовый ущерб от сбоев или утечек.
При недостатке внутренней экспертизы или для независимого взгляда логично привлекать внешних специалистов. Они могут привнести опыт из других проектов и знание редких векторов атак.
Что нужно уметь для проведения оценки
Глубина анализа напрямую зависит от квалификации команды. Нужен баланс между теорией и практикой.
| Область компетенций | Необходимые знания и навыки |
|---|---|
| Теоретическая база | Понимание фреймворков управления рисками (ISO 27005, NIST RMF). Знание матрицы тактик и техник MITRE ATT&CK. Понимание классификаций уязвимостей и инцидентов. |
| Практические навыки | Умение анализировать логи систем и приложений, сетевые дампы. Опыт работы со сканерами уязвимостей. Базовое понимание методологии тестирования на проникновение для реалистичной оценки возможностей атакующего. |
| Регуляторный контекст | Глубокое знание структуры и логики Банка данных угроз ФСТЭК. Понимание требований 152-ФЗ и подзаконных актов, особенно в части обоснования выбора мер защиты именно выявленными угрозами. |
Особенности для облачной инфраструктуры и ЦОД
Использование внешней инфраструктуры не снимает ответственности за оценку угроз, но смещает фокус. Оператор обязан провести оценку во взаимодействии с облачным провайдером, запросив его модель угроз для платформы. Если провайдер предоставляет формальную отписку или отказывается, в модели необходимо исходить из пессимистичного сценария: часть инфраструктуры может уже контролироваться квалифицированным нарушителем. Это прямое обоснование для дополнительных мер криптографической защиты данных, строгой сегментации на уровне приложений и активного мониторинга аномалий.
Что такое модель угроз безопасности информации
Модель угроз — это формализованный результат оценки. Это структурированный документ, описывающий систему, её критические активы, профили нарушителей, актуальные угрозы и сценарии их реализации. Актуализировать её нужно не строго по календарю, а по событиям:
- Выход новых нормативных требований или значительное обновление Банка данных угроз ФСТЭК.
- Существенные изменения в архитектуре системы (миграция, внедрение нового критичного сервиса, интеграция).
- Появление публичных эксплойтов для компонентов, используемых в системе.
- Результаты внутренних аудитов безопасности, расследований инцидентов или учений Red Team, выявившие новые векторы атак.
Как проходит процесс оценки угроз
Процесс можно представить как три взаимосвязанных, повторяющихся блока.
- Определение негативных последствий. Сначала нужно ответить на вопрос «Что мы теряем?». Без понимания ущерба невозможно правильно расставить приоритеты. Например, утечка базы клиентов — это не просто технический сбой, а прямая угроза репутации, риск судебных исков и штрафов от регулятора по 152-ФЗ.
- Определение объектов воздействия и профилей нарушителей. Выявление того, что именно атакуют (например, сервер приложений, СУБД, канал передачи данных) и кто это может сделать с учётом его мотивации, ресурсов и исходного уровня доступа.
- Оценка реализуемости и финальное определение актуальности. Технический анализ: существуют ли известные, неустранённые уязвимости в используемом ПО? Можно ли реализовать угрозу через цепочку из нескольких низкоуровневых уязвимостей? Насколько сложен сценарий для предполагаемого нарушителя с учётом имеющихся у него средств?
Визуализация процесса оценки угроз
Что должно получиться в итоге
Итогом является не просто отчёт, а актуализированная модель угроз, которая напрямую связывает выявленные актуальные угрозы с конкретными активами и профилями нарушителей. Этот документ служит прямым обоснованием для:
- Выбора, настройки и оптимизации средств защиты информации (МЭ, SIEM, DLP, WAF).
- Разработки или корректировки регламентов реагирования на инциденты для конкретных, наиболее опасных сценариев атак.
- Обоснованного планирования бюджета на ИБ, где каждая затратная мера имеет понятную привязку к закрываемой угрозе и оценке возможного ущерба.
От абстракции к конкретике: сценарии угроз
Работа с угрозами — это их постоянная конкретизация. Вместо абстрактной «несанкционированной утечки информации» необходимо рассматривать детализированный сценарий: «Внутренний нарушитель (сотрудник отдела продаж) копирует базу клиентов на личный USB-накопитель, обходя политики DLP из-за не обновлённого агента на своей рабочей станции». Классификация по источникам помогает систематизировать работу, но практическую ценность представляет именно такой детальный сценарий, который можно смоделировать, протестировать и против которого можно выстроить конкретные контрмеры.
Как понять, какая угроза актуальна
Актуальность угрозы — это производная от вероятности её реализации и тяжести возможных последствий. Вероятность оценивается не интуитивно, а на основе объективных факторов:
- Наличие и доступность средств эксплуатации (exploits) для известных уязвимостей в технологическом стеке системы. Публичный эксплойт в Metasploit резко повышает вероятность атаки.
- Сложность проведения атаки: требует ли она уникального zero-day эксплойта, дорогостоящего оборудования или может быть выполнена с помощью общедоступных скриптов и базовых навыков.
- Необходимый исходный уровень доступа нарушителя: доступ из интернета, учётная запись авторизованного пользователя или физический доступ к оборудованию.
Угрозы, прямо указанные в Банке данных угроз ФСТЭК или подтверждённые частыми инцидентами в отрасли, автоматически получают высокий приоритет. Итоговая матрица актуальности — это инструмент для принятия решений о распределении всегда ограниченных ресурсов на защиту.
Как оценка угроз связана с другими процессами ИБ
Оценка угроз выступает центральным узлом, связывающим различные практики ИБ в единую систему. Её выводы напрямую питают и определяют:
- Проектирование и изменение архитектуры (принцип минимальных привилегий, микросегментация сети, secure by design).
- Выбор и обоснование контролей (мер защиты) из требований регуляторов — становится ясно, почему применяются именно эти меры, а другие, менее релевантные, могут быть опущены.
- Настройку систем мониторинга и реагирования (SIEM, SOAR): правила корреляции и сценарии реагирования строятся под конкретные выявленные сценарии атак, а не под общие шаблоны.
- Планирование программ тестирования защищённости (пентесты, Red Team): их фокус смещается на проверку устойчивости к наиболее актуальным и опасным угрозам из модели.
Без этой связующей роли меры защиты часто становятся разрозненными, неэффективно расходуют ресурсы, а соответствие регуляторным требованиям (включая 152-ФЗ) рискует превратиться в формальность, не обеспечивающую реальной безопасности.