Служба ИБ защищает бюджет теми же аргументами, что и любое подразделение: сколько стоит, что это дало, как измерено. Анализ рисков переводит угрозы в суммы, метрики показывают результат.

CISO и финансовый директор у большого экрана с дашбордом рисков и графиками, деловая переговорная, приглушенный свет

Ниже расчетный контур: формулы, метрики, критерии выбора решений и обоснование инвестиций.

Анализ рисков информационной безопасности: процесс и методологии

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

Что такое анализ рисков ИБ и его место в цикле риск-менеджмента

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

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

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

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

Методика обеспечения информационной безопасности: обзор фреймворков (ISO 27005, NIST SP 800-30, OCTAVE, FAIR)

Методика обеспечения информационной безопасности в части анализа рисков опирается на один из четырех международных фреймворков либо на методику ФСТЭК. Различаются они входными данными и трудозатратами.

Методология	Подход	Входные данные	Выходные артефакты	Применимость	Трудозатраты
ISO/IEC 27005:2022	Сценарии риска, смешанный	Активы, процессы, критерии	Реестр рисков, план обработки	База для СМИБ	Средние
NIST SP 800-30	Качественный, детальные шкалы	Источники угроз, уязвимости	Оценка по шкалам	Крупные ИТ-ландшафты	Средние
FAIR	Количественный, декомпозиция	Частота событий, статистика ущерба	Распределение потерь в деньгах	Обоснование бюджета	Высокие
OCTAVE	Качественный, самооценка	Мнения владельцев процессов	Профили рисков активов	Компании без аналитиков	Низкие
Методика ФСТЭК 2021	Сценарный, реализуемость	БДУ, архитектура, потенциал нарушителя	Модель угроз	ГИС, ИСПДн, КИИ	Средние

ISO/IEC 27005:2022 разделяет два подхода к идентификации: классический «актив — угроза — уязвимость» и событийный, от сценариев и последствий. Второй экономит время при большом числе однотипных активов. Смешивать фреймворки правильно: процесс по ISO, перечень угроз по методике ФСТЭК, расчет по FAIR для десяти самых дорогих рисков.

Информационная безопасность: метод оценки рисков по требованиям ФСТЭК и ЦБ РФ

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

Информационная безопасность как метод оценки рисков в российской практике — связка: перечень угроз по методике ФСТЭК и БДУ, реализуемость через потенциал нарушителя, последствия в терминах ущерба физическим лицам, организации и государству.

Для финансового сектора добавляется контур Банка России: полнота процессов проверяется при оценке по ГОСТ Р 57580. Практика проверок — в материале про методику оценки и аудит ИБ.

Количественная и качественная оценка рисков

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

Качественные методы: матрицы рисков, экспертные оценки, heat maps

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

Три условия, без которых матрица бесполезна:

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

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

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

Количественные методы: расчет ALE (Annual Loss Expectancy), SLE, ARO по методологии FAIR

Количественная оценка переводит риск в годовые ожидаемые потери: формулы простые, сложность в исходных данных.

SLE (Single Loss Expectancy) — ущерб от одного инцидента: стоимость актива × коэффициент воздействия
ARO (Annual Rate of Occurrence) — ожидаемая частота реализации за год
ALE (Annual Loss Expectancy) — годовые ожидаемые потери: ALE = SLE × ARO

Пример. Клиентская база оценена в 40 млн рублей, коэффициент воздействия при утечке 0,4 — SLE равен 16 млн. При частоте раз в пять лет ARO составляет 0,2, годовые ожидаемые потери — 3,2 млн.

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

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

декомпозиция риска по FAIR — частота событий потерь и величина потерь с разложением на первичные и вторичные составляющие

Риски, связанные с информационной безопасностью: приоритизация и выбор стратегии обработки

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

Отсечка идет по порогу принятия — риск-аппетиту (risk appetite), который руководство утверждает до начала оценки. Решение по каждому риску фиксируется письменно: неоформленное равно молчаливому принятию.

Порядок работы с реестром:

Отсортировать риски по ALE или позиции в матрице
Отсечь то, что ниже порога принятия
Оценить стоимость снижения оставшихся
Выбрать стратегию: снижение, принятие, передача, избегание
Назначить ответственного и срок

Оценка эффективности информационной безопасности

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

Оценки эффективности информационной безопасности: KPI, KRI и метрики зрелости

Оценки эффективности информационной безопасности строятся на двух группах показателей: KPI измеряют результативность процессов, KRI (Key Risk Indicator) сигнализируют о росте риска до его реализации.

Метрика	Как считается	Ориентир	Частота	Источник данных
Время обнаружения	Медиана от события до выявления	Часы, не дни	Ежемесячно	SIEM
Время реагирования	От выявления до локализации	До 4 часов для критичных	Ежемесячно	Система заявок
Время восстановления	До штатной работы	Не выше RTO	По инцидентам	Владельцы процессов
Покрытие сканированием	Просканированные активы к общему числу	Выше 95%	Ежемесячно	Сканер
Срок устранения критичных уязвимостей	От обнаружения до закрытия	До 30 дней	Ежемесячно	Сканер, заявки
Доля рисков с владельцем	Риски с ответственным к общему числу	100%	Ежеквартально	Реестр рисков
Риски выше порога	Число рисков в красной зоне	Снижение к периоду	Ежеквартально	Реестр рисков
Доля обученного персонала	Прошедшие обучение к штату	Выше 90%	Раз в полгода	Система обучения
Отклик на учебный фишинг	Перешедшие по ссылке к получившим	Снижение к периоду	Ежеквартально	Платформа симуляций
Привилегированные записи под контролем	Управляемые к общему числу	100%	Ежеквартально	Управление доступом

Метрики зрелости оценивают устойчивость процесса: пятиуровневая шкала показывает, выполняется он разово, регулярно или измеряется и улучшается. Подходы к оценке зрелости — в исследовании АФТ.

Как измерить ROI от внедрения СЗИ и обосновать бюджет перед бизнесом

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

Пример для системы предотвращения утечек. Ожидаемые потери от утечки клиентской базы 3,2 млн рублей, коммерческих условий 2,5 млн. Внедрение снижает частоту вдвое: потери падают до 2,85 млн, при стоимости владения 1,8 млн чистый эффект около 1 млн в год.

Совет принимает расчет при трех условиях: вероятность из статистики, стоимость владения на три года, названа величина остаточного риска.

Второй аргумент — избежание штрафов. За повторную утечку персональных данных предусмотрен оборотный штраф в 1–3 процента выручки: не менее 20 млн и не более 500 млн рублей. Для специальных категорий и биометрии минимум составляет 25 млн.

расчет ROI от внедрения системы предотвращения утечек — ожидаемые потери до и после, стоимость владения, чистый эффект по годам

Бенчмаркинг: сравнение эффективности ИБ с отраслевыми показателями

Бенчмаркинг отвечает на вопрос правления «а у других так же?». Сравнивают три показателя: долю затрат на ИБ в ИТ-бюджете, время обнаружения и восстановления, зрелость процессов.

По оценкам отраслевых аналитиков, в 2026 году расходы на информационную безопасность составляют в среднем 7–10 процентов ИТ-бюджета: финансовый сектор и субъекты КИИ выше, торговля и производство ниже. Ограничение метода проговаривается сразу — отраслевые цифры собраны по разнородным выборкам и годятся как ориентир, но не как обоснование бюджета.

Оценка технологии информационной безопасности

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

Оценка технологии информационной безопасности: критерии выбора СЗИ и вендоров

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

Критерий	Тип	Что проверять
Сертификат ФСТЭК или ФСБ	Отсекающий для ГИС, КИИ, ИСПДн	Номер, класс, срок, область применения
Совместимость с инфраструктурой	Отсекающий	Поддержка ОС, виртуализации, интеграции
Функциональность	Сравнительный	Покрытие сценариев из модели угроз
Реестр отечественного ПО	Отсекающий при импортозамещении	Наличие записи, актуальность
TCO на три года	Сравнительный	Лицензии, внедрение, поддержка, персонал
Поддержка и SLA	Сравнительный	Сроки реакции, наличие русскоязычной линии
Зрелость вендора	Сравнительный	Срок на рынке, число внедрений, планы

Два реестра проверяются отдельно: запись в реестре отечественного ПО отвечает на вопрос «отечественное ли», сертификат ФСТЭК — «соответствует ли требованиям защиты». Продукт бывает в одном и отсутствует в другом. Классы средств защиты и их соответствие требованиям регулятора разобраны в материале про техническую защиту информации и средства защиты.

TCO (Total Cost of Ownership) и скрытые затраты на внедрение и эксплуатацию

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

Что попадает в расчет помимо лицензий:

Внедрение и интеграция с существующими системами, часто через подрядчика
Инфраструктура: серверы, хранилище, лицензии на виртуализацию
Продление лицензий и поддержки — 15–25 процентов стоимости в год
Персонал: администрирование, разбор срабатываний, обучение
Стоимость выхода: миграция данных при смене решения

структура TCO средства защиты — единовременные и периодические затраты по годам, доля скрытых расходов

Пилотные проекты и PoC (Proof of Concept): как тестировать решения до закупки

PoC проверяет одну гипотезу: закрывает ли решение сценарии из вашей модели угроз в вашей инфраструктуре. Демонстрация на стенде вендора такой проверкой не является.

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

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

Регуляторные требования к оценке рисков в РФ

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

Требования ФСТЭК (Приказы №17, 21, 239) к методикам оценки рисков

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

Уточнение по нумерации. Приказ № 17 по государственным информационным системам утратил силу: с 1 марта 2026 года действует Приказ № 117, где появились требования к проверке знаний персонала не реже раза в три года.

Приказ № 21 требует оценки эффективности принятых мер не реже раза в три года, Приказ № 239 распространяется на значимые объекты КИИ.

Проект изменений в приказы № 235 и № 239 вводит регулярный расчет показателей защищенности и зрелости мер: планируется с 1 сентября 2026 года, на момент подготовки материала не принят. Категорирование закрывает услуга по безопасности объектов КИИ.

Требования ЦБ РФ (ГОСТ Р 57580, Положения 683-П, 719-П) к анализу рисков в финансовом секторе

Банк России встраивает риск информационной безопасности в контур операционного, профильный документ — Положение № 716-П. Оценка полноты процессов идет по ГОСТ Р 57580.2 с привлечением сторонней организации не реже раза в два года.

Номера положений изменились. Положение № 683-П заменено № 851-П с 29 марта 2025 года, № 719-П — № 821-П с 1 апреля 2024 года. Во внутренних документах старые номера встречаются до сих пор.

По 851-П установлена поэтапность: до 31 декабря 2026 года — минимальный уровень защиты с уровнем соответствия не ниже третьего, с 2027 года стандартный с уровнем не ниже четвертого. Оценку проводит организация с лицензией ФСТЭК на техническую защиту информации, внутренний аудит требование не закрывает — услуга по ГОСТ Р 57580.

Гармонизация российских и международных подходов (ISO 27001:2022, NIST CSF)

Российские и международные требования во многом пересекаются, два параллельных процесса не нужны. Путь один — единый реестр рисков с двойной маркировкой: пункт российского документа и контроль Приложения А ISO/IEC 27001:2022.

NIST CSF 2.0, вышедший 26 февраля 2024 года, добавил к пяти функциям шестую — Govern, про ответственность руководства и стратегию управления риском. Сертификации по CSF нет, поэтому он удобен как каркас отчетности перед правлением.

Поправка ISO/IEC 27001:2022/Amd 1:2024 добавила требование оценить релевантность климатического фактора. Новых контролей она не вводит, но при надзорном аудите вопрос задают. Подготовку к сертификации закрывает услуга по ISO 27001.

Инструменты и автоматизация

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

GRC-платформы и системы управления рисками: обзор российских решений

Класс решений называется SGRC — Security Governance, Risk and Compliance. Платформа связывает активы, угрозы, риски, меры и требования в одну структуру и дает прослеживаемость от пункта документа до настройки средства защиты.

На российском рынке представлены R-Vision SGRC, Security Vision и «КиберОснова». Функциональность зрелых решений сопоставима: управление активами, моделирование угроз со справочниками БДУ, качественная и количественная оценка рисков, контроль соответствия, управление уязвимостями. Платформа не решает критерии приемлемости, обоснование исключения угроз и оценку потенциала нарушителя — это экспертные решения.

дашборд SGRC-платформы — реестр рисков, статусы обработки, соответствие требованиям, динамика показателей

Автоматизация сбора данных для анализа рисков и отчетности

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

Что дает реальную отдачу:

Инвентаризация активов из систем управления конфигурациями и сканеров
Подтягивание уязвимостей с автообновлением статусов
Сбор метрик инцидентов из SIEM и системы заявок
Контроль сроков обработки рисков с эскалацией просрочек
Сборка отчетности для комитета по рискам

Чек-лист: 10 шагов для проведения комплексного анализа рисков ИБ в организации

Порядок отражает реальную последовательность работ: пропуск шага обнаруживается на следующем.

Утвердить критерии риска и порог принятия у руководства до начала оценки
Определить границы: системы, процессы, площадки, подрядчики
Инвентаризировать активы, назначить владельцев процессов
Собрать перечень угроз из БДУ ФСТЭК и данных об инцидентах
Оценить уязвимости сканированием и пентестом
Выбрать метод: качественный по реестру, количественный по верхней части
Рассчитать риски и разместить на матрице
Выбрать стратегию обработки с ответственным и сроком
Задать метрики контроля и периодичность их снятия
Определить триггеры пересмотра и владельца процесса

десять шагов анализа рисков с распределением по этапам, ответственным и выходным артефактам

Оформление результатов во внутренних документах разобрано в статье про организационное обеспечение ИБ.

FAQ: частые вопросы об анализе рисков и оценке эффективности

Чем качественный анализ рисков отличается от количественного, и когда какой применять?

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

Как рассчитать ROI от внедрения системы DLP или EDR для Совета директоров?

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

Обязательно ли использовать методологию FAIR, или достаточно качественных матриц рисков?

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

Как часто нужно проводить повторный анализ рисков по требованиям ФСТЭК?

Жесткой периодичности методика не задает, актуализация привязана к изменениям системы и условий эксплуатации. По Приказу № 21 оценка эффективности мер проводится не реже раза в три года. Практика — пересмотр раз в год плюс внеплановый по триггерам.

Какие метрики лучше всего показывают эффективность ИБ: количество инцидентов, время реакции, покрытие сканированием?

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

Как оценить TCO (совокупную стоимость владения) для облачных vs on-premise решений ИБ?

Считать на одном горизонте, обычно три года, и по одинаковому составу статей. У on-premise выше единовременные вложения, у облака периодические платежи: на коротком горизонте облако выигрывает, на длинном не обязательно. В расчет включают персонал, стоимость выхода и требования к размещению данных.

Нужно ли согласовывать методику оценки рисков с регулятором (ФСТЭК, ЦБ РФ)?

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

Как провести PoC (пилотный проект) для оценки технологии ИБ перед закупкой?

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