Что такое SGRC и как автоматизировать комплаенс в информационной безопасности

Представьте: за неделю до проверки руководитель ИБ собирает ответ на простой вопрос — «Где у нас хранятся персональные данные клиентов и кто за это отвечает?». Ответ разбросан по трём таблицам, двум версиям положения о ПДн и переписке с ИТ. Одна таблица обновлялась полгода назад, во второй владелец системы уже уволился. Формально всё есть. Фактически — никто не может показать картину целиком.

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

Почему «Excel и папка с политиками» перестают работать

Пока требований мало, таблица справляется. Проблемы начинаются, когда регуляторных контуров становится несколько, систем — десятки, а изменения идут каждый месяц. Таблица не знает, что требование из 152-⁠ФЗ и мера из внутреннего стандарта касаются одной и той же CRM. Она не напомнит о просроченном устранении и не пересчитает риск, когда закрыли уязвимость.

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

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

Что такое SGRC: три составляющие

SGRC расшифровывается как Security Governance, Risk and Compliance. Буква S подчёркивает, что речь именно об информационной безопасности, а не о корпоративном GRC в целом (финансовый контроль, внутренний аудит бизнеса). Внутри — три взаимосвязанных направления.

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

Цикл SGRC: от нормативки до устранения по PDCA

Рабочий SGRC-⁠процесс — это цикл, а не разовый проект. Его удобно описывать через модель PDCA (Plan — Do — Check — Act), знакомую по ISO/IEC 27001: спланировали, выполнили, проверили, скорректировали — и пошли на новый круг.

1. Нормативка. Загружаем документы — закон, приказ регулятора, внутреннюю политику — и выделяем из них конкретные требования.
2. Процессы. Связываем требования с ИТ-⁠активами и процессами, назначаем владельцев и ответственных.
3. Риски. Оцениваем, что будет, если требование не выполняется или мера не работает, и выбираем стратегию обработки.
4. Аудиты. Проверяем, как требования выполняются на практике, фиксируем несоответствия.
5. Устранение. Ставим корректирующие действия со сроком и ответственным, контролируем исполнение и обновляем оценку рисков.

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

Управление рисками ИБ: качественная оценка и расчёт в рублях

Управление рисками ИБ обычно начинается с качественной оценки. Для каждого риска задают вероятность и ущерб по шкале (например, от 1 до 5), перемножают и получают уровень. Результат раскладывают на карту рисков — матрицу, где сразу видно, что в «красной зоне». Метод быстрый и понятный, но у него есть слабость: «4 из 5» ничего не говорит финансовому директору.

Количественная оценка переводит разговор на язык бюджета. Классическая метрика — ALE (Annualized Loss Expectancy), годовые ожидаемые потери. Её считают как произведение ущерба от одного события (SLE, Single Loss Expectancy) на ожидаемую частоту событий в год (ARO, Annualized Rate of Occurrence).

Дальше выбирают стратегию обработки риска: снизить (внедрить меры), передать (страхование, аутсорсинг), принять (осознанно, с подписью владельца) или избежать (отказаться от деятельности, которая его порождает). Хорошая SGRC-⁠система позволяет вести обе оценки параллельно: качественную — для оперативной карты рисков, количественную — для приоритизации бюджета.

Аудиты и опросные листы самооценки

Аудит в SGRC — это не только выездная проверка. Большая часть контроля в крупной компании идёт через опросные листы самооценки: владельцы систем и подразделений отвечают на вопросы по требованиям, прикладывают подтверждения, а служба ИБ проверяет ответы выборочно.

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

Слабое место самооценки понятно: владелец системы отвечает «да, выполняется», потому что так проще. Поэтому зрелые команды подкрепляют ответы фактическими данными из инфраструктуры — об этом ниже.

Регуляторные контуры РФ: соответствие 152-⁠ФЗ и КИИ 187-⁠ФЗ

Для российских компаний два контура встречаются чаще всего. 152-⁠ФЗ «О персональных данных» касается практически любого оператора ПДн: он требует обеспечить безопасность персональных данных, а при сборе ПДн граждан РФ — запись, хранение и обработку с использованием баз данных на территории России. Состав мер защиты детализирован в подзаконных актах, в частности в постановлении Правительства №1119 и приказе ФСТЭК №21. При утечке ПДн оператор обязан уведомить Роскомнадзор в установленные сроки: первичное уведомление — в течение 24 часов, результаты внутреннего расследования — в течение 72 часов.

187-⁠ФЗ «О безопасности критической информационной инфраструктуры» распространяется на субъектов КИИ — организации из перечисленных в законе отраслей. Ключевые обязанности: категорировать объекты КИИ, обеспечить безопасность значимых объектов (требования — в приказе ФСТЭК №239), взаимодействовать с ГосСОПКА и сообщать о компьютерных инцидентах.

В одной компании контуры пересекаются: одна и та же система может обрабатывать ПДн и одновременно быть объектом КИИ. SGRC позволяет увидеть это пересечение и не делать одну работу дважды — одна мера закрывает требования нескольких документов.

Сквозной пример: одно требование 152-⁠ФЗ от документа до дашборда

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

1. 01

   Документ

   В реестр загружен 152-⁠ФЗ. Из него выделено требование «хранить ПДн граждан РФ в базах данных на территории РФ».

2. 02

   Требование → система

   Требование связано с ИТ-⁠активом «CRM-⁠клиенты», у системы есть владелец и ответственный за соответствие.

3. 03

   Риск

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

4. 04

   Аудит

   Плановый аудит находит несоответствие: нет журнала учёта машинных носителей, на которые выгружаются данные из CRM.

5. 05

   Задача на устранение

   Создано корректирующее действие: ввести журнал учёта носителей, срок — 30 дней, ответственный — администратор CRM. Просрочка подсветится на дашборде.

6. 06

   Инцидент и уведомление

   Если утечка всё же произошла, процесс запускает подготовку уведомления в Роскомнадзор в установленные сроки. После закрытия задачи оценка риска пересматривается, и на дашборде риск снижен.

Главное в этом примере — прослеживаемость. На вопрос «почему мы потратили время на журнал носителей?» есть ответ в одну цепочку: закон → требование → система → риск → находка аудита → задача.

Связь SGRC с AM, VM, SIEM и ITSM: факты вместо самооценки «на глаз»

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

Так самооценка «на глаз» заменяется проверяемыми данными. Если владелец отвечает «уязвимости закрываются в срок», а сканер показывает критичную уязвимость полугодовой давности, противоречие видно сразу. А когда инцидент требует действий, SGRC-⁠процесс может опираться на сценарии реагирования — о них в материале что такое SOAR.

Как выбрать GRC систему: чек-⁠лист

Рынок SGRC-⁠решений неоднороден: от «конструктора опросников» до тяжёлых платформ, которые требуют перестроить процессы под продукт. Вот вопросы, которые стоит задать до пилота.

1. Гибкость под ваш регламент. Можно ли смоделировать свои роли, карточки, маршруты согласований и метрики — или придётся подгонять процессы под продукт?
2. Модель связей. Связаны ли документы, требования, активы, риски, аудиты и несоответствия между собой, а не лежат в отдельных списках?
3. Две оценки рисков. Есть ли качественная матрица и расчёт в рублях, выбор стратегии обработки?
4. Любой регуляторный контур. Можно ли добавить новый документ и требования без доработки вендором?
5. Интеграции. Получает ли система данные из сканеров, SIEM, ITSM и кадровых систем, или всё вводится руками?
6. Отчётность. Строятся ли отчёты руководству и регулятору из данных, есть ли карта рисков и контроль просрочек?
7. Развёртывание и лицензии. Ставится ли решение в ваш контур, работает ли на отечественных ОС, нет ли ограничений по числу пользователей и активов?

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

Как это устроено в Versium SGRC

Модуль Versium SGRC начинается с каталога требований: в нём 31 документ — 187-⁠ФЗ, 152-⁠ФЗ, приказы ФСТЭК № 239, 21 и 17, постановление Правительства № 127, документы ФСБ и NIST CSF. По требованиям ведутся оценки с техническими свидетельствами, причём заключение специалиста хранится отдельно от технического факта: видно, что показала проверка и как её оценил человек. С требованиями связаны меры, риски и задачи, а пересмотр оценок сохраняет историю.

Модель данных SGRC та же динамическая, что у всей платформы: роли, таблицы, поля и связи настраиваются в конструкторе под ваш регламент без остановки сервиса. Модуль входит в единую платформу Versium вместе с SOAR, AM и VM. Посмотреть цикл на ваших процессах можно на демонстрации.