Я наблюдал ситуации, когда компания формально соответствует требованиям регулятора, регулярно проходит аудиты, имеет утвержденные Политики, настроенные СЗИ, выделенный SOC и несколько сотен страниц Регламентов на случай любой проверки.
Но после первого инцидента выяснялось, что:
Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.
Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.
Но здесь легко попасть в ловушку формального контроля, ведь соответствие требованиям — это подтверждение того, что определенные правила и процедуры существуют. Требования задают определенный минимальный уровень контроля, но не могут описать всю конкретную инфраструктуру компании, все зависимости между системами, особенности бизнес-процессов и все возможные сценарии атаки.
Предлагаю посмотреть на области, которые уже соответствуют требованиям, немного другим взглядом. Рассмотрим MFA, SIEM, управление доступом, DLP и прочие моменты с точки зрения слабых мест бумажной безопасности.
№1. Управление доступом
Классическая проверка часто выглядит довольно просто: открыл карточку пользователя — посмотрел назначенные роли. Но современные корпоративные инфраструктуры редко устроены настолько просто:
права могут наследоваться через группы;
группы могут быть вложенными;
доступ может назначаться через роли приложений;
часть полномочий приходит из Active Directory, часть — из локальных каталогов приложений, часть — через облачные сервисы.
В результате пользователь может не иметь ни одной явно назначенной привилегированной роли, но при этом обладать весьма серьезными полномочиями. Условно: пользователь — группа А — группа Б — роль — ресурс.
Но это ещё ничего. В некоторых случаях проблема возникает, когда у пользователя не «слишком много» прав, а когда он получил вполне допустимые права, которые вместе создают недопустимый сценарий. Допустим, у сотрудника есть доступ к системе платежей, но нет права непосредственно проводить операции.
Отдельно у него есть доступ к справочнику контрагентов.
Отдельно — возможность изменять определённые реквизиты.
Каждое разрешение по отдельности может быть легитимным, но комбинация полномочий создаёт возможность изменить данные так, что можно влиять на финансовую операцию (SoD-конфликт). Именно поэтому зрелое управление доступом должно анализировать не только отдельные права, но и комбинации полномочий.
Как исправить?
На практике я начинаю не с проверки списка ролей пользователя, а с построения его эффективной модели доступа. То есть смотрю не только на то, какие роли ему назначены напрямую, а прохожу всю цепочку наследования: учетная запись, группы, вложенные группы, роли приложений, права на конкретные информационные системы и критичные операции.
Особенно внимательно стоит смотреть на привилегированные и конфликтующие полномочия.
Для таких проверок я использую выгрузки из IAM и каталогов учетных записей, данные из прикладных систем и матрицы доступа. В крупных инфраструктурах без автоматизации быстро упираешься в объём: вручную проверить несколько тысяч пользователей и десятки тысяч связей практически невозможно.
Отдельно я бы рекомендовал регулярно искать «сиротские» права: доступы пользователей, которые уже сменили должность, не используют конкретную систему или вообще должны были быть отключены.
Главный результат такой проверки для меня не количество найденных нарушений. Важнее понять, можем ли мы для каждого критичного доступа ответить на три вопроса:
кто им обладает;
зачем он ему нужен;
что произойдет, если этот доступ будет скомпрометирован.
№2. SIEM
На этапе внедрения обычно обсуждают количество источников, EPS, правила корреляции, хранение и стоимость инфраструктуры. Но после запуска появляется более сложная задача: расследование.
Представим, что мы хотим понять, что делал пользователь за два часа до подозрительной операции.
В Active Directory он имеет один идентификатор.
В VPN используется логин в другом формате.
В EDR устройство связано с третьим идентификатором.
В бизнес-приложении пользователь представлен внутренним UUID.
Часть сетевых событий вообще содержит только IP-адрес.
При этом DHCP уже выдал этот адрес другому устройству.
События есть, но нет готовой цепочки: пользователь — устройство — IP — приложение — действие.
А почему нет? Точнее, почему её может не быть? Обычно вопрос количества логов не стоит — их у всех достаточно. Препятствия бывают с качеством телеметрии и её нормализацией, когда события невозможно связать между собой. Здесь даже очень дорогая SIEM не сможет превратить их автоматически в полноценную картину инцидента.
Как исправить?
При проектировании мониторинга я бы оценивал не только количество подключенных источников. Эффективнее взять один реальный сценарий атаки и пройти его от начала до конца: какое событие появится первым, где оно окажется, с чем будет связано, кто и как его увидит, какие дополнительные данные сможет получить аналитик и сможет ли он восстановить всю цепочку действий. Если на каком-то этапе приходится вручную искать информацию в пяти разных системах, это уже часть проблемы.
№3. MFA
Многофакторная аутентификация — обязательный элемент современной защиты. Но здесь тоже легко попасть в ловушку формального контроля.
Допустим, сотрудник действительно проходит MFA. Что это дает? Снижается вероятность успешного использования украденного пароля. Но после успешной аутентификации возникает другая сущность — сессия.
Если злоумышленник получает действующий токен или иным способом использует уже авторизованную сессию, то включена MFA или не включена, — не так уж и важно. Важны другие механизмы:
Контроль жизненного цикла сессий.
Привязка сессии к контексту устройства.
Анализ активности.
Повторная аутентификация для критичных операций.
Контроль изменения параметров сессии.
Обнаружение резкого изменения географии или характера работы.
Причем здесь особенно хорошо видно, почему нельзя строить безопасность вокруг отдельных продуктов. MFA — это один контроль, EDR — другой, UEBA — третий, SIEM — четвертый, а атака проходит через инфраструктуру, а не «продукты». Поэтому важно понимать, какой участок цепочки атаки закрывает каждый контроль и что происходит между ними.
Как исправить?
При настройке контроля я обращаю внимание на жизненный цикл сессии: срок действия токена, возможность его повторного использования, требования к повторной аутентификации, привязку к устройству и контексту доступа.
Для критичных операций полезно отдельно проверять, требуется ли повторное подтверждение. Например, вход в корпоративное приложение с нового устройства и изменение реквизитов платежа не должны рассматриваться как одно и то же по уровню доверия.
Кроме того, MFA не должна существовать изолированно. Её эффективность существенно повышается, если события аутентификации связаны с данными IAM, EDR, VPN и SIEM.
Тогда вместо простого события «пользователь успешно прошёл MFA» мы можем увидеть контекст:
пользователь вошел впервые с нового устройства;
подключился из нетипичной сети;
через несколько минут получил повышенные полномочия;
после этого начал обращаться к ресурсам, с которыми раньше не работал.
Каждый признак отдельно может быть допустимым. Вместе они уже требуют внимания.
Поэтому при проверке MFA я стараюсь тестировать не только сам механизм второго фактора, но и сценарии его обхода и использования уже авторизованной сессии.
Это гораздо ближе к реальной модели угроз, чем простая галочка «MFA включена».
№4. Исключения
Это категория, которую часто недооценивают. Как часто вы слышали эти фразы:
«У нас так принято».
«Эта система всегда была доступна из этой сети».
«Эти учетные записи давно никто не трогает».
«Это временно, потом исправим».
Практически в любой крупной инфраструктуре есть системы, которые нельзя сразу перевести на стандартные политики:
Старое приложение требует нестандартного сетевого доступа.
Критичная система не поддерживает современный механизм аутентификации.
Отдельный сервис должен работать с расширенными привилегиями.
Создаётся исключение. Изначально оно абсолютно рационально, но позже создаёт проблему, потому что инфраструктура меняется, появляются новые СЗИ, приложение модернизируется, ответственные сотрудники меняются, а исключение остается. Два-три года — и уже никто не помнит, почему оно вообще было создано. В результате стандартное правило может выглядеть очень хорошо, а несколько исторических исключений фактически формируют отдельный контур безопасности.
Поэтому исключения должны иметь не только владельца и обоснование. У них должен быть срок жизни. Если исключение нельзя пересмотреть через год, например, то возникает вопрос: «А почему оно, собственно, ’’исключение’’?»
Как исправить?
Сделать исключения управляемыми.
Полностью избавиться от исключений в крупной инфраструктуре практически невозможно. Но задача ИБ не в том, чтобы запретить исключения, а в том, чтобы не позволить им превратиться в постоянную дыру в защите.
На практике, я бы вёл отдельный реестр исключений с такими полями:
какое требование нарушается;
для какой системы;
по какой причине;
кто владелец риска;
какой срок действия;
какие компенсирующие меры применяются.
Последний пункт особенно важен.
Если систему невозможно подключить к современному механизму аутентификации, это не означает, что остается только написать в документе «невозможно технически». Можно ограничить сетевую доступность, разрешить доступ только с определенных станций, усилить мониторинг, добавить дополнительные проверки или ограничить круг пользователей.
То есть исключение должно иметь цену. Если мы не можем применить основной контроль, мы должны понимать, чем компенсируем этот недостаток.
Ещё одна практика, которую я считаю полезной, это автоматический пересмотр исключений. У исключения должна быть дата, когда его снова необходимо рассмотреть. Иначе временное решение очень быстро становится частью архитектуры.
Особенно опасны исключения без владельца. Если через год никто не может ответить, кто и зачем разрешил конкретный обход контроля, такое исключение уже само по себе является находкой для аудита.
№5. DLP
Еще одна интересная история происходит с защитой от утечек. Представим, что пользователь выгрузил 5 ГБ документов. На первый взгляд это серьезный повод для блокировки. Но добавим контекста:
пользователь работает в подразделении, которое регулярно формирует архивы;
выгрузка выполняется в рабочее время;
получатель — внутренний корпоративный ресурс.
И вот уже такая операция может быть абсолютно нормальной.
Теперь другой сценарий. Пользователь обычно работает с несколькими десятками мегабайт в день. Но сегодня в 02:00 он впервые подключился с нового устройства, скачал несколько гигабайт архивов, после чего попытался передать их во внешний сервис. Объем тот же и с точки зрения простой сигнатурной логики — просто 5 ГБ, но по контексту совершенно другая история.
Поэтому эффективный контроль утечек данных давно не ограничивается вопросом: «Сколько данных передано?». Всё гораздо интереснее: кто, что, откуда, куда, когда, каким способом и насколько это соответствует его обычному поведению?
И именно здесь становится особенно важной интеграция DLP, IAM, UEBA, сетевой телеметрии и данных о бизнес-контексте. Отдельный продукт может увидеть только часть картины, а инцидент возникает на пересечении этих данных.
Как исправить?
Добавлять контекст к событиям DLP.
При настройке DLP я бы отдельно проверял не только политики блокировки, но и качество классификации данных, корректность исключений и интеграцию с IAM, SIEM и UEBA.
Очень важно также не пытаться блокировать всё подозрительное автоматически. Для критичных сценариев автоматическая блокировка оправдана, а для пограничных случаев лучше передать событие аналитику с максимально полным контекстом.
В противном случае можно получить классическую проблему DLP: система формально защищает данные, но сотрудники начинают искать способы обойти её из-за большого количества ложных срабатываний.
№6. Время
Представим, что на одном сервере время отличается на 3 минуты. На другом используется другой часовой пояс. Ещё одна система пишет время в UTC.
Часть событий приходит в SIEM с задержкой и для обычной эксплуатации это может быть незаметно, а во время расследования трехминутная разница способна полностью изменить последовательность событий. А последовательность для расследования критична. Что было первым?
Компрометация учетной записи?
Создание нового процесса?
Подключение к серверу?
Выгрузка данных?
Изменение прав?
Если временная шкала построена неправильно, то и аналитик может сделать неверный вывод даже при наличии всех необходимых событий. Поэтому качество телеметрии это не только вопрос того, собираются ли логи, это ещё и вопрос того, насколько этим логам можно доверять.
Как исправить?
Начать стоит с единого источника времени для всей инфраструктуры. На критичных системах я проверяю не только наличие NTP, но и то, откуда конкретно система получает время, насколько стабильно работает синхронизация и что происходит при недоступности основного источника.
Но одной синхронизации недостаточно. Для SIEM важно привести события к единому формату времени и явно понимать, какое время записано в каждом событии: время возникновения события на источнике, время его обработки или время поступления в SIEM. Это три разных значения, и смешивать их при расследовании сильно нежелательно.
Отдельно можно проверять задержку доставки событий. Например, сервер может корректно зафиксировать событие в 02:13, но SIEM получить его только в 02:16. Если аналитик строит временную шкалу только по времени поступления, последовательность действий уже будет искажена.
Поэтому при проверке мониторинга я обычно смотрю на несколько вещей: синхронизацию времени, единый часовой пояс и формат временных меток, задержку доставки событий и наличие технических меток, позволяющих отличить время события от времени его поступления.
И самое главное, это нужно проверять не на уровне документации, а на практике: создать несколько контролируемых событий на разных системах, зафиксировать фактическое время их возникновения и посмотреть, в каком порядке они появляются в SIEM.
Если после такого теста невозможно уверенно сказать, какое событие произошло первым, значит проблема уже не в NTP. У нас проблема с доказательной базой для расследования.
№7. Автоматическое реагирование
Чем больше СЗИ появляется, тем сильнее желание автоматизировать реакцию.
Обнаружили подозрительную активность — заблокировали пользователя.
Нашли подозрительный процесс — остановили.
Увидели аномальное подключение — заблокировали IP.
С технической точки зрения все логично. Но автоматизация сама становится источником риска.
Представим, что UEBA ошибочно определила нормальную активность привилегированного пользователя как аномальную и система блокирует учетную запись. А это единственный человек, который в данный момент может устранить критичную неисправность в продуктивной среде.
Получается парадокс: защитный механизм сам создаёт отказ в обслуживании. Поэтому автоматизация должна учитывать не только вероятность атаки, но и стоимость ошибочной блокировки.
Автоматическая блокировка может быть оправдана для одного сценария, а для другого правильнее будет создать высокий приоритет и передать решение аналитику. И мы снова возвращаемся к вопросу, что необходимо понимать не технологию, а бизнес-контекст.
Как исправить?
Не стоит спешить с автоматизацией всего, что кажется поддающимся автоматизации. Сначала нужно определить, какие последствия будет иметь ошибка автоматического действия.
Условно, все реакции можно разделить на несколько уровней:
Первый уровень — действия с минимальным влиянием на бизнес. Например, добавить IP-адрес или хеш файла в дополнительный список мониторинга, повысить приоритет события, собрать дополнительную информацию об узле.
Второй — обратимые действия. Например, временно ограничить сетевое соединение или изолировать рабочую станцию от сети. Здесь уже необходимо понимать, что произойдет с бизнес-процессом и как быстро вернуть всё в штатное состояние.
Третий — критичные действия: блокировка привилегированной учетной записи, отключение сервера, остановка процесса, изменение прав доступа. Такие реакции я бы разрешал автоматически только для хорошо проверенных сценариев с низкой вероятностью ложного срабатывания и понятным механизмом отката.
На практике полезно начинать с режима, в котором автоматическое правило сначала только фиксирует событие и предлагает действие аналитику. По результатам работы можно оценить количество ложных срабатываний и только после этого переводить конкретный сценарий в автоматический режим.
Отдельно нужно работать с исключениями. Например, если автоматизированное правило изолирует рабочие станции, должны существовать понятные условия для критичных серверов, аварийных учётных записей и других объектов, блокировка которых может привести к более серьёзным последствиям, чем сама угроза.
И обязательно должен существовать механизм отката. Если система автоматически заблокировала пользователя или изолировала сервер, должно быть понятно, кто, на основании чего и за какое время может вернуть его в рабочее состояние.
В итоге, автоматизацию стоит оценивать не по количеству действий, которые выполняются без участия человека, а по более ценному показателю — сколько времени она действительно экономит при приемлемом уровне риска ошибочной реакции.
Как бы я проверял зрелость ИБ?
Вообще, если посмотреть на большинство зрелых инфраструктур, можно заметить одну закономерность — проблема редко находится внутри одного средства защиты. Она возникает на стыке:
IAM знает, кто пользователь.
EDR знает, что происходило на его АРМе.
SIEM видит последовательность событий.
DLP знает, какие данные передавались.
Сетевая инфраструктура знает, куда устанавливалось соединение.
PAM записал сессию.
Но если эти данные не связываются, каждый продукт видит только свою часть атаки. Например, EDR фиксирует запуск PowerShell, прокси видит соединение с внешним ресурсом, DLP видит обращение к чувствительному файлу, а IAM знает, что пользователь недавно получил повышенные права.
По отдельности ни одно событие может не быть критичным. Вместе же они формируют опасную цепочку. Потому зрелость ИБ-инфраструктуры я бы оценивал не только по набору решений, а по тому, насколько хорошо они складываются в единую модель событий.
Есть достаточно простой подход: вместо того чтобы составлять очередной список из сотни пунктов, можно взять несколько наиболее опасных для конкретной организации сценариев, например, компрометация привилегированной учетной записи, и пройти всю цепочку:
Как получен доступ?
Что видит IAM?
Что видит EDR?
Какие события попадают в SIEM?
Как обнаруживается аномалия?
Что происходит с сессией?
Кто принимает решение?
Какие действия будут предприняты?
Такие проверки дают намного больше информации, чем ревизия документов или очередной чек-лист. Хоть чек-листы могут быть очень полезны, но у них есть фундаментальное ограничение — они хорошо отвечают на вопрос: «Выполнено ли условие?» И плохо отвечают на вопрос: «Что произойдет, если несколько условий одновременно будут нарушены?» Потому архитектурные проверки должны дополняться сценарным тестированием.
Отдельно затронем метрики
Есть ещё одна проблема зрелой ИБ — неправильные метрики. Например, можно гордиться тем, что SOC обработал 50 000 алертов за месяц, но само число ничего не говорит, потому что можно сократить количество алертов в 10 раз и одновременно ухудшить безопасность, если просто отключить некоторое количество правил, а можно увеличить количество обнаруженных инцидентов и решить, что ситуация стала хуже, хотя по факту обнаружение улучшилось.
Поэтому метрика должна быть связана с конкретным результатом:
Не «SIEM подключила 500 источников», а «Для X% критичных сценариев атаки SOC получает достаточный набор телеметрии для расследования».
Не «Резервное копирование выполняется ежедневно», а «Критичная система восстанавливается за X часов при заданном сценарии отказа».
Не «Права пользователей пересматриваются ежеквартально», а «X% привилегированных доступов имеют подтвержденного владельца, бизнес-обоснование и актуальную дату пересмотра».
Заключение
Самая опасная иллюзия в ИБ это слепая вера в защиту, когда компания защищает свою инфраструктуру большим количеством правильных средств, но не знает, насколько хорошо они работают вместе.
MFA есть, но остается риск компрометации сессии.
PAM есть, но существуют обходные пути.
SIEM есть, но телеметрия не позволяет восстановить цепочку событий.
и т.д. и т.п.
Именно поэтому я бы не задавал вопрос: «Соответствует ли наша система требованиям ИБ?», так как правильнее задавать несколько более неприятных вопросов:
Что конкретно произойдет при компрометации привилегированной учетной записи?
Что мы увидим в первые 5 минут?
Какие данные позволят восстановить цепочку атаки?
Какие защитные механизмы атакующий сможет обойти?
Что произойдет, если один из них откажет?
И самое главное:
Можем ли мы доказать на практике, что наша защита работает именно в том сценарии, от которого она должна нас защищать?
Но здесь не нужно противопоставлять compliance и техническую безопасность. Требования нужны. Аудиты нужны. Регламенты нужны. Но их правильнее воспринимать как нижний уровень системы управления.
После того, как требование выполнено, мы должны понимать, а какой реальный риск мы этим контролем снижаем? Как мы проверим, что риск действительно снизился?
Если «понимание» заключается только в наличии документа, отчёта или установленного класса решений, контроль, скорее всего, оценивается слишком формально. Если же можно показать реальный сценарий, измерить результат и воспроизвести его повторно, ситуация уже совсем другая.
Соответствие требованиям — это подтверждение того, что определённые правила и процедуры существуют. А информационная безопасность начинается там, где эти правила сталкиваются с реальной инфраструктурой, реальными ограничениями и реальной атакой.
Читайте также:
