ГК Softline: почему оценка киберрисков превращается в бюрократию и как это исправить

Представьте себе ситуацию: в компании обнаружили критическую уязвимость.

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

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

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

Зачем бизнесу оценивать киберриски

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

Оценка рисков помогает ответить на четыре вопроса:

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

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

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

Поэтому в Softline мы рекомендуем начинать с анализа бизнес-процессов и критичных активов, а уже затем переходить к оценке технических угроз.

Почему универсальной методологии не существует

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

По опыту Softline, при выборе методологии необходимо учитывать несколько факторов.

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

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

ISO, NIST, FAIR и российские методики: в чем различия

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

ISO/IEC 27005: системный подход к рискам

ISO/IEC 27005 описывает процесс управления рисками информационной безопасности: определение контекста, выявление угроз, анализ, оценку, обработку и последующий мониторинг.

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

Главное преимущество ISO/IEC 27005 — гибкость. Подход можно встроить в систему менеджмента информационной безопасности (СМИБ) и согласовать с требованиями ISO/IEC 27001.

Он подходит компаниям, которые выстраивают или совершенствуют СМИБ, международному бизнесу и поставщикам услуг, работающим с зарубежными заказчиками.

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

NIST: подробная структура и контроль исполнения

Подходы Национального института стандартов и технологий США (NIST) полезны компаниям, которым важны формализованные процессы и четкое распределение ответственности.

Здесь нужно различать два инструмента.

• NIST SP 800-30 содержит рекомендации непосредственно по оценке рисков: подготовке, проведению оценки и поддержанию результатов в актуальном состоянии.
• NIST Risk Management Framework (RMF) описывает более широкий процесс управления рисками информационных систем. Он включает подготовку, категоризацию систем, выбор и внедрение мер защиты, оценку их эффективности, авторизацию и непрерывный мониторинг.

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

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

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

FAIR: когда киберриски нужно перевести в деньги

Factor Analysis of Information Risk (FAIR) — модель количественной оценки информационных рисков. Она помогает оценивать возможные финансовые потери с учетом частоты событий и величины ущерба. Для бизнеса это принципиальное отличие от качественных шкал.

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

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

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

ГОСТ и ФСТЭК: российская нормативная специфика

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

ГОСТ Р ИСО/МЭК 27005-2021 содержит рекомендации по управлению рисками информационной безопасности, основанные на международном подходе. Нормативные документы ФСТЭК России устанавливают требования к защите различных категорий информационных систем и объектов. Среди них — приказы № 17, № 21, № 31 и № 239, относящиеся к разным видам систем и условиям их защиты.

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

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

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

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

Как выбрать подход без лишних затрат

Выбор методологии зависит от задач компании. ISO/IEC 27005 подходит для системного управления рисками, NIST RMF — для детальной организации процессов и контроля защитных мер, а FAIR помогает оценивать возможный финансовый ущерб. Российские ГОСТ и документы ФСТЭК применяются с учетом нормативных требований к конкретным организациям и системам.

В Softline мы рекомендуем комбинировать подходы. Например, использовать ISO/IEC 27005 для организации процесса, NIST Cybersecurity Framework для структурирования рисков и FAIR для оценки наиболее существенных угроз в денежном выражении. Главное — закрепить выбранную методику во внутренних документах и определить единые критерии оценки и порядок принятия решений.

Почему оценка рисков часто не работает

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

1. Реестр существует только для аудитора

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

2. У риска нет владельца

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

3. Оценка не успевает за изменениями инфраструктуры

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

4. Технические показатели не связаны с ущербом

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

Как изменить ситуацию

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

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

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

Автоматизация, количественные модели и ИИ: куда развивается оценка рисков

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

Непрерывная оценка рисков

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

Непрерывная оценка рисков (Continuous Risk Assessment) помогает учитывать такие изменения оперативнее. Для этого можно интегрировать реестр рисков с системами управления событиями информационной безопасности (SIEM), данными об актуальных киберугрозах (Threat Intelligence), базами конфигурационных единиц (CMDB) и инструментами управления уязвимостями. Так компания получает возможность обновлять оценки по мере поступления новых данных. При этом непрерывный сбор информации не означает, что каждое изменение требует полного пересмотра всех рисков. Важно определить события, которые действительно влияют на их уровень.

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

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

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

GRC-платформы: меньше ручной работы, больше требований к данным

Платформы управления, рисками и соответствием требованиям (Governance, Risk and Compliance, GRC) помогают автоматизировать сбор информации, ведение реестров и контроль выполнения мероприятий. Это сокращает объем ручных операций, но не решает проблему качества исходных данных. Если база ИТ-активов устарела, сведения об уязвимостях неполные, а связь информационных систем с бизнес-процессами не определена, автоматизированная оценка будет воспроизводить эти недостатки.

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

Искусственный интеллект: ускорение анализа и новые ограничения

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

Результаты моделей могут быть непрозрачными, их качество способно изменяться со временем, а ошибки в исходных данных — приводить к некорректным выводам, поэтому мы в Softline рассматриваем ИИ как вспомогательный инструмент риск-аналитика. Алгоритм может предложить оценку или сценарий, но решение о допустимости риска, необходимых инвестициях и возможных последствиях остается за человеком.

Как внедрить оценку рисков, которая будет полезна бизнесу

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

В Softline мы предлагаем выстраивать эту работу последовательно:

1. Проверьте исходное состояние

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

2. Определите, кому нужны результаты

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

3. Комбинируйте инструменты

Необязательно ограничиваться одной методологией. Компания может использовать ISO/IEC 27005 для организации процесса, NIST для структурирования отдельных задач и FAIR для финансовой оценки критичных рисков. Главное — установить единые критерии, определить владельцев рисков и зафиксировать порядок принятия решений.

4. Свяжите оценку с изменениями бизнеса

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

5. Оценивайте остаточный риск

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

6. Пересматривайте саму методологию

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

Что важно помнить руководителям и командам ИБ

Какую методологию выбрать для начала?

ISO/IEC 27005 можно использовать как основу процесса управления рисками. Если компании необходима более подробная организация работы с информационными системами, стоит рассмотреть инструменты NIST.

Как объяснять киберриски руководству?

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

Когда нужна FAIR?

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

Кто должен отвечать за риск?

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

Можно ли полностью автоматизировать процесс?

Автоматизировать можно сбор данных, часть расчетов, обновление реестров и контроль мероприятий. Но экспертная проверка и принятие решений остаются необходимыми.

Вместо вывода: хорошая оценка рисков заканчивается решением

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

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

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

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