Управление рисками информационной безопасности без единой методологии быстро превращается в набор разрозненных мер. Один отдел ведет таблицу инцидентов, другой — список уязвимостей, третий отслеживает требования регуляторов. Такой подход не дает полной картины рисков и не помогает принимать взвешенные решения о приоритетах защиты.
GRC — Governance, Risk and Compliance — объединяет корпоративное управление, управление рисками и соблюдение требований в единый процесс. Если вы только разбираетесь с основами концепции, начните с материала «Что такое GRC». В этой статье — практика: как выстроить процесс управления рисками ИБ шаг за шагом.
Три этапа управления рисками ИБ
Управление рисками проходит три последовательных этапа: идентификацию, оценку и обработку.
Идентификация — инвентаризация активов и угроз. На этом шаге фиксируют, что нужно защищать: информационные системы, базы данных, инфраструктуру, бизнес-процессы. Затем определяют, какие угрозы актуальны для каждого актива. Источники: результаты пентестов, отчеты об инцидентах, базы уязвимостей CVE и NVD, отраслевые аналитические отчеты.
Оценка — расчет уровня риска по двум параметрам: вероятность реализации угрозы и величина потенциального ущерба. Оценка бывает качественной (уровни «высокий — средний — низкий»), количественной (в денежном выражении) или смешанной. Выбор метода зависит от зрелости процессов и наличия данных для расчетов.
Обработка — принятие решения по каждому риску. Четыре варианта:
- принять риск, если ущерб ниже стоимости мер защиты;
- передать риск через страхование или аутсорсинг;
- снизить риск с помощью технических и организационных мер;
- избежать риска, отказавшись от рискованной практики или технологии.
После обработки цикл повторяется: риски пересматривают при изменениях в инфраструктуре, законодательстве или ландшафте угроз.
Реестр рисков как инструмент управления
Реестр рисков — документ, в котором хранятся все идентифицированные риски, их оценки, ответственные лица и статус обработки. Без реестра трудно контролировать, что уже закрыто, а что требует внимания.
Типовые поля реестра:
- описание угрозы и уязвимости, которую она эксплуатирует;
- затрагиваемые активы и бизнес-процессы;
- оценка вероятности и ущерба;
- итоговый уровень риска и выбранная стратегия обработки;
- плановые и фактические сроки закрытия;
- ответственный владелец риска.
GRC-платформы автоматизируют ведение реестра: связывают риски с контролями, отслеживают статус задач, строят отчеты для руководства и готовят документацию к аудитам. BI.ZONE GRC хранит историю изменений по каждому риску и уведомляет владельцев о приближающихся дедлайнах.
Соответствие требованиям в GRC-процессе
Управление рисками в российских компаниях неотделимо от соответствия регуляторным требованиям. Три основных фреймворка, с которыми работает GRC-специалист:
152-ФЗ «О персональных данных» требует классифицировать обрабатываемые ПД по уровням защищенности (УЗ-1–УЗ-4) и вести реестр операторов. Несоответствие ведет к штрафам и проверкам Роскомнадзора.
Требования ФСТЭК России охватывают государственные информационные системы (ГИС) и информационные системы персональных данных (ИСПДн). Приказы № 17 и № 21 задают конкретные наборы мер защиты в зависимости от класса и уровня защищенности системы.
ISO 27001 — международный стандарт управления информационной безопасностью. Строится на цикле Plan–Do–Check–Act и охватывает весь спектр контролей: от физической безопасности до управления инцидентами. Стандарт нередко требуют партнеры при заключении международных контрактов.
GRC-система соотносит идентифицированные риски с требованиями нужных фреймворков и показывает, какие контроли уже выполнены, а какие — в работе. Это сокращает время подготовки к аудитам и внешним проверкам.
Политики ИБ и их связь с управлением рисками
Политики ИБ — формализованные правила, которые определяют допустимое поведение сотрудников, подрядчиков и систем. Они работают только тогда, когда привязаны к конкретным рискам и контролям.
Пример связки «риск — контроль — политика»:
- Идентифицировали риск утечки данных через съемные носители.
- Выбрали контроль: запрет несанкционированных USB-устройств.
- Зафиксировали в политике допустимого использования ИТ-ресурсов.
- Подтвердили техническими мерами — DLP-системой и групповыми политиками AD.
Без документирования этой связки контроль существует изолированно и не отслеживается в рамках GRC-процесса. Политики, оторванные от реестра рисков, быстро устаревают и перестают отражать актуальные угрозы.
Метрики зрелости управления рисками
Метрики показывают, насколько хорошо работает процесс. Они делятся на два типа.
Операционные метрики отражают активность процесса: число идентифицированных рисков за период, доля рисков с назначенным владельцем, процент просроченных задач по обработке.
Результирующие метрики фиксируют эффект: снижение числа критических рисков от квартала к кварталу, сокращение среднего времени закрытия уязвимостей, количество успешно пройденных аудитов без существенных замечаний.
Дашборды GRC-платформы визуализируют метрики в режиме реального времени и автоматически формируют отчеты для CISO и совета директоров. Это переводит разговор об ИБ на язык бизнес-рисков и упрощает обоснование бюджетов.
Роль GRC-специалиста в команде
GRC-специалист выстраивает и поддерживает процесс управления рисками. Основные задачи:
- разработать и актуализировать методологию оценки рисков;
- вести реестр рисков и контролей;
- координировать оценки с владельцами систем и бизнес-процессов;
- готовить компанию к аудитам и проверкам регуляторов;
- отслеживать изменения в законодательстве и адаптировать политики.
Специалист работает на пересечении информационной безопасности, права и бизнеса. Он переводит технические риски в деловые последствия и помогает руководству принимать решения, опираясь на данные, а не на интуицию.
Хорошая GRC-программа строится не на единственном специалисте, а на процессе: задокументированные процедуры, реестр рисков в платформе и регулярные циклы пересмотра работают независимо от ротации сотрудников.
Частые вопросы
С чего начать внедрение GRC-процесса?
Начните с инвентаризации активов и определения области применения. Прежде чем оценивать риски, нужно понять, что именно защищать: системы, данные, процессы. Параллельно зафиксируйте регуляторные требования, которым компания обязана соответствовать.
Чем GRC-платформа отличается от реестра в Excel?
Таблица не отслеживает историю изменений, не связывает риски с контролями и не строит автоматических отчетов. GRC-платформа хранит аудиторский след, уведомляет владельцев рисков о дедлайнах, интегрируется со сканерами уязвимостей и SIEM-системами.
Нужно ли соответствовать всем стандартам одновременно?
Нет. Набор фреймворков зависит от отрасли, типа обрабатываемых данных и требований клиентов. GRC-процесс помогает расставить приоритеты и выбрать стандарты, которые дают максимальный охват при минимальных затратах на дублирующие контроли.
Как часто пересматривают реестр рисков?
Плановый пересмотр — раз в год или при существенных изменениях в инфраструктуре, законодательстве или ландшафте угроз. Отдельные риски обновляют по факту инцидентов, результатов пентестов или аудитов.
Кто такой владелец риска?
Владелец риска — сотрудник, ответственный за принятие решения по конкретному риску и реализацию мер обработки. Это не всегда специалист по ИБ: если риск связан с конкретным бизнес-процессом, владельцем нередко назначают руководителя подразделения.
Практика на стендах BI.ZONE Cybersecurity Labs
Курс на платформе BI.ZONE Cybersecurity Labs дает возможность отработать управление рисками на изолированных стендах, которые воспроизводят реальную корпоративную инфраструктуру. вы пройдете полный цикл: от первичного аудита и построения реестра рисков до подготовки документации под требования ФСТЭК и 152-ФЗ.
Практические задания охватывают работу непосредственно с BI.ZONE GRC: настройку методологии оценки, ведение реестра контролей, формирование отчетов для регулятора. Стенды изолированы, поэтому можно экспериментировать, не затрагивая production-среду.