Управление информационной безопасностью в компаниях с распределённой структурой — головная боль для многих руководителей служб безопасности. Создать единый защищённый периметр — цель, которая выходит далеко за рамки разработки регламентов. Сложность в том, чтобы обеспечить их внедрение в каждом филиале, организовать непрерывный контроль и оперативно реагировать на меняющиеся условия на местах. Как совместить единые требования безопасности с локальными особенностями филиалов и при этом не скатиться в самообман абсолютного контроля расскажет Светлана Осина, руководитель группы проектирования отдела систем мониторинга и реагирования Angara Security.
Когда жёсткие стандарты на практике не работают
Представьте классическую ситуацию. Головной офис на основе лучших практик обновляет и актуализирует стандарты безопасности компании. Затем обновлённые стандарты направляются в региональные подразделения, где начинаются сложности: в одном филиале работает критически важное, но устаревшее ПО, которое не поддерживает новые требования, в другом — непреклонные правила «ломают» уникальные бизнес-процессы. Через время выясняется, что жёсткие требования не работают: где-то нашли неофициальный обход, где-то новые правила тихо игнорируются.
Жёсткие, негибкие стандарты в компаниях с распределённой структурой часто лишь имитируют порядок. Необходимо построить такую систему, где филиал может обоснованно и открыто отклониться от общих стандартов, но этот шаг будет виден, взвешен, одобрен и поставлен под контроль. Для этого следует найти баланс между жёсткостью требований и гибкостью к локальной специфике, а затем воплотить этот баланс в жизнь.
Фундамент системы: единые политики с регламентированным механизмом исключений
Спускать стандарты сверху как директиву, не учитывая «человеческий фактор» региональных команд – верный способ нарваться на саботаж.
Намного эффективнее сделать филиалы соавторами новых правил. Одним из вариантов может стать внедрение модели «Белого списка исключений»: каждый филиал раз в квартал подаёт не формальную жалобу на неудобный стандарт, а приходит с готовым предложением по его адаптации под себя и с аргументами, почему так будет лучше.
Соревновательный элемент может подстегнуть интерес к процессу. Тот филиал, который предложит самое лучшее решение — где и риски минимальны, и бизнес не страдает, — получает, например, дополнительный бюджет на развитие локальной ИБ-инфраструктуры. Такой подход переводит оппозиционеров в союзников, снижает желание «обходить» правила и превращает процесс управления исключениями в источник инноваций.
Но сами правила игры при этом должны быть строгими и прозрачными. Корпоративные политики безопасности утверждаются на уровне головного офиса, и в них заранее прописывается чёткий механизм локальных исключений. Запрос на отклонение от стандарта — не просто устная просьба или короткое сообщение в чате, он должен содержать техническое и бизнес-обоснование. Почему стандарт неприменим? Какие конкретные процессы или системы не позволяют его выполнить? Необходимо провести оценку возникающих рисков: какие новые угрозы появляются из-за этого исключения. Должен быть разработан план компенсирующих мер контроля, в котором филиал опишет, как планирует минимизировать эти риски другими способами. И, конечно, нужно обозначить чёткий срок действия. Для каждого исключения необходим конкретный период, по истечении которого ситуация будет пересмотрена.
Утверждать такие запросы должен головной офис. Это позволяет видеть полную картину, а также обеспечить всестороннюю оценку рисков для всей компании, а не для одного филиала.
SGRC: учёт рисков
Как измерить риск от того или иного исключения? Одним из наиболее эффективных инструментов для этого являются системы комплексного управления информационной безопасностью, рисками и соответствием регуляторным требованиям (Security Governance, Risk and Compliance, SGRC).
SGRC-платформа помогает формализовать процесс. Она превращает разрозненные запросы из почты и чатов в структурированный реестр. Каждое исключение регистрируется, проходит утверждённые этапы рассмотрения и получает статус. SGRC позволяет рассчитать риск: применить различные методики для качественной и количественной оценки рисков (оценить потенциальный ущерб и вероятность реализации угрозы из-за разрешённого отклонения). Вместо субъективного мнения «Это опасно» появляется расчёт, например:
«Принимая это исключение, повышается риск инцидента с утечкой данных на 15%, что в денежном выражении может составить до 5 000 000 рублей».
Система также обеспечивает постоянный контроль и отслеживает сроки действия всех исключений, автоматически напоминает о необходимости их пересмотра и формирует отчёты.
Однако просто посчитать ущерб недостаточно — важно сопоставить его с затратами на «легализацию» исключения. В таком случае, отклонение возможно только тогда, когда стоимость компенсирующих мер (дополнительный дежурный SOC-аналитик, усиленное логирование, внеплановое обновление сигнатур) оказывается ниже потенциальных потерь от вероятного инцидента. Если же исключение экономически нецелесообразно, головной офис получает право не отклонять его, а профинансировать модернизацию проблемного участка (например, замену устаревшего ПО). Такой подход позволяет устранить причину исключения, а не бороться годами с его последствиями.
Без SGRC исключения существуют в серой зоне: о них быстро забывают, их риски не проходят повторную оценку, и в итоге общая картина безопасности становится необъективной.
SIEM: единый источник данных
После утверждения исключений остаётся вопрос: как сохранить контроль над филиалами? Необходима техническая реализация, иначе любые заверения звучат так:
«Мы будем внимательно следить», — фраза, которая никого не убеждает и не даёт реальных рычагов воздействия.
Основой для такого контроля должна стать централизованная система сбора и корреляции событий информационной безопасности (SIEM). SIEM должна стать «единым источником данных» для всей распределённой компании.
До внедрения SIEM диалог между центром и филиалом строится на мнениях: «У нас всё безопасно» против «Мы вам не верим». SIEM меняет правила игры и становится базой для диалога. Головной офис видит в единой консоли факты: «В филиале 40% рабочих станций не получали критические обновления за последний месяц, а журналирование событий входа в ключевую систему отключено». Исключения запрашиваются и обсуждаются на основе этих данных.
Ещё одна важная функция SIEM — измеримость последствий. Допустим, филиалу разрешили временно не обновлять устаревшую, но важную систему. В SIEM это исключение можно сопроводить конкретными контрольными метриками:
«Усилить мониторинг сетевой активности этой системы, установить пороги срабатывания правил корреляции в два раза ниже текущего и ежедневно отслеживать появление индикаторов компрометации, связанных с уязвимостями системы».
Контроль становится осязаемым и измеримым.
Общие дашборды SIEM, доступные и центру, и филиалам, ликвидируют информационную асимметрию и создают прозрачность и доверие. Все стороны работают с одними и теми же данными, что создаёт основу для взаимного доверия и продуктивного сотрудничества.
SOAR: автоматизирует исполнение и обеспечивает единые процессы
Если SIEM — это «глаза и уши» безопасности, то системе оркестрации, автоматизации и реагирования (Security Orchestration, Automation and Response, SOAR) отводится роль «рук и ног». SOAR гарантирует, что даже в условиях локальных исключений базовые процессы безопасности работают одинаково надёжно по всей компании.
Платформа SOAR позволяет стандартизировать сценарии реагирования: создать плейбуки (сценарии) для обработки инцидентов. Неважно, какая ИТ-инфраструктура есть в филиале и какие исключения действуют для сценария «Ответ на фишинг-атаку», в этом случае будет выполняться один и тот же набор действий: изоляция заражённого письма, блокировка вредоносных ссылок, оповещение сотрудников и сбор артефактов.
SOAR регламентирует процессы: платформа отслеживает время реакции на каждом этапе и автоматически передаёт сложные инциденты из филиала центральной команде экспертов, если локальные специалисты не справляются или нарушают сроки. Таким образом, автоматическая эскалация и контроль решают проблемы «тихого саботажа», низкой квалификации на местах или простой забывчивости. Головной офис видит статус каждого инцидента в реальном времени и может вмешаться при необходимости.
Прозрачность, отчётность и культура: организационная основа
Технические решения должны быть неразрывно связаны с организационными мерами: дашборд для руководства, регулярные пересмотры исключений для филиалов и общее формирование культуры безопасности. Руководители должны видеть ключевые метрики безопасности (уровень риска, количество активных исключений, время реакции на инциденты) по всем филиалам в одном окне в реальном времени. Локальные исключения «к делу не пришьёшь». В рамках процесса управления рисками необходимо регулярно пересматривать их эффективность и актуальность (например, ежеквартально). Вовлечение руководителей филиалов в процессы оценки рисков, разъяснение логики принимаемых решений снижают сопротивление внедрению стандартов.
Вместо финала
Таким образом, единые стандарты информационной безопасности в распределённой компании — это в первую очередь создание прозрачной системы, в основе которой лежат чёткие политики с заранее предусмотренным механизмом для обоснованных отклонений. Для организации процесса, в рамках которого каждое исключение оценивается, утверждается и ставится на контроль, эффективным решением будет использовать SGRC-системы, а для организации процессов мониторинга и реагирования, обеспечивающих контроль и дисциплину, использовать SIEM и SOAR.
Такая архитектура превращает ИБ-службу из «надзирателя» в «бизнес-партнера». Когда филиал видит, что его специфика учитывается, а исключение не влечёт за собой санкций, а лишь усиленный мониторинг, уровень доверия растёт, и инциденты перестают замалчиваться.
Плюсом становится накопленный в SGRC реестр исключений — золотая жила для стратегической аналитики. Если 80% отклонений связаны с одним типом устаревшего ПО или специфическим сетевым протоколом, это чёткий сигнал для головного офиса: пора менять архитектуру, а не множить компенсирующие меры.
Важно помнить, что предложенные технические средства — лишь инструменты, задача которых — обеспечить выполнение целей и требований ИБ. Реальную безопасность создают не они, а люди, эксперты, которые грамотно их применяют. И именно этот синтез технологий и человеческого разума позволяет получить максимальную устойчивость бизнеса к киберугрозам.
