Передоз кибербезом. «МойОфис» рассказал, как большое число ИБ-продуктов мешает работе, и что с этим делать

Мои будни — это внедрение сложных систем защиты. Я знаю, что компании тратят огромные бюджеты на покупку «самых лучших»  средств защиты. И я же видел, как все эти инвестиции превращаются в цифровые руины из-за одной фундаментальной, системной ошибки. Проблема сегодняшней информационной безопасности — не в отсутствии инструментов, а в отсутствии смысла в их использовании. Несмотря на рост количества развернутых систем, 99% предупреждений они либо генерируют вхолостую, либо их попросту не видят, потому что не настроена процедура сбора и корреляции.

Технические аспекты проблемы сбора событий

Основная беда начинается на этапе получения событий. Каждое средство защиты по умолчанию настроено на максимально подробное логирование. Фаерволл рапортует о каждом разрешенном и заблокированном пакете, система предотвращения вторжений (IPS) видит угрозу в каждом втором HTTP-запросе, а EDR (Endpoint Detection and Response) заваливает оператора уведомлениями о каждом подозрительном, но легитимном процессе. Объем сырых данных исчисляется терабайтами в сутки. Это не информация — это шум. И в этом шуме тонет тот самый единственный критический инцидент, который и приведет к утечке данных или масштабному взлому.

Аспект 1: Отсутствие политики логирования и фильтрации на источнике

Главная техническая ошибка — отправка в SIEM всего подряд без разбора. Необходимо внедрять политику фильтрации событий непосредственно на источниках генерации логов. Например:

Для межсетевых экранов (NGFW) вместо выгрузки всех разрешающих правил (allow) имеет смысл настроить фильтрацию по событиям, попадающим под правила с высоким уровнем риска (попытки доступа к неиспользуемым сервисам, связи с негативными IP-субъектами), а также все блокировки (deny). Критически важно настроить отправку логов о любых изменениях конфигурации самого FW.

Для систем EDR нужно отключить информационный шум (например, детектирование легитимных портативных исполняемых файлов) и сфокусироваться на реально опасных действиях: попытки отключения защиты, запуск скриптовых интерпретаторов (powershell, wscript) с подозрительными параметрами, попытки повышения привилегий, подозрительные сетевые соединения с хостов.

Для Windows-серверов — не надо загружать в SIEM все Event Logs. Нужно сконфигурировать политику аудита и отправлять только события, релевантные для безопасности: успешные и неуспешные попытки входа (4624, 4625), изменения в группах администраторов (4670), попытки доступа к критичным файлам (4663). Это снизит нагрузку на сеть и систему хранения в десятки раз.

Аспект 2: Некорректная парсинг-нормализация данных

События из разных систем приходят в разных форматах. Один и тот же логин пользователя в Windows будет в поле User, в Cisco ASA — в поле user, а в Linux — в src_user. Без качественной нормализации (приведения к единому виду) корреляция невозможна. SIEM-система должна правильно парсить каждое входящее событие, извлекать из него IP-адреса, имена пользователей, хеши файлов и приводить их к единому стандарту. Частая ошибка — неверно написанный парсер для кастомного приложения, который приводит к тому, что критичное событие просто не попадает в дальнейший анализ.

Аспект 3: Отсутствие контекста и обогащения

Сырое событие «Блокировка соединения на IP 95.123.76.211» мало о чем говорит. Но если обогатить его данными из Threat Intelligence Feeds (провайдеров угроз) и добавить контекст: «IP 95.123.76.211 принадлежит хосту bullet.vpn.badactor.tld, находится в блэк-листе MITRE по категории ‘C2 сервер’», — это сразу поднимает критичность инцидента до максимального уровня. Отсутствие подключенных источников актуальной информации об угрозах — это работа вслепую.

Технические аспекты настройки корреляции

Следующий пласт проблемы — регистрация и корреляция. SIEM-система, призванная быть «мозгом» центра управления безопасностью, часто превращается в дорогой архив логов. Загрузить в нее события — полдела. Второе, и главное, — научить ее понимать связи между ними. Одно событие — это всего лишь точка. Десять событий из разных систем, связанные временем и целью, — это уже линия атаки.

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

Правила корреляции низкого уровня

Пример — «5 неуспешных попыток входа в систему с последующим успешным входом». Это базовый сценарий brute force. Но его нужно адаптировать под каждую систему.

Сложные кросс-платформенные правила

Вот где кроется настоящая сила. Пример цепочки атаки:

• Событие от EDR: На рабочей станции пользователя запущен процесс powershell.exe с параметром, пытающимся отключить антивирусное ПО.
• Событие от NGFW: Через 2 минуты с этой же рабочей станции установлено шифрованное (TLS) соединение на внешний IP-адрес, не принадлежащий доверенным облачным провайдерам компании.
• Событие от DLP: Через 5 минут зафиксирована попытка отправки большого объема данных (500 Мб) через веб-сокет.

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

Техническая организация процесса реагирования

Но даже если мы преодолели первые два этапа и получили качественный, релевантный алерт, нас поджидает третья и самая «человеческая» ловушка — отрабатывание инцидентов. Зачастую в компании просто не существует регламента: что делать, когда система кричит «Караул!».

Кто этот алерт получает? Кто его анализирует? Кто принимает решение о его эскалации? Кто и как его закрывает? Без четкого процесса (playbook) даже самый громкий сигнал бедствия утонет в бесконечных переписках.

Система тикетов (SOAR)

Идеальный алерт должен автоматически создавать тикет в системе инцидентного реагирования (Jira, ServiceNow или специализированном SOAR) с заранее проставленным уровнем критичности, категорией и назначенным ответственным аналитиком.

Плейбуки (Playbooks)

Для каждого типа инцидентов должны быть заранее прописаны пошаговые инструкции для аналитика. Например, для алерта «Подозрение на фишинг»:

• Заблокировать URL в системе фильтрации трафика.
• Найти по логам прокси всех пользователей, перешедших по ссылке за последние N часов.
• Принудительно сменить этим пользователям пароли.
• Запустить сканирование EDR на их хостах. Это ускоряет реакцию в разы и исключает человеческую ошибку.

Этап автоматизации

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

Что же делать? Решение лежит не в технологической, а в процессной плоскости.

Во-первых, необходимо начинать не с покупки, а с проектирования. Прежде чем внедрять очередной инструмент, задайте вопросы: какие угрозы он должен детектировать? Какие события для этого критичны? Как они будут доставляться в SIEM? Как будут коррелировать с событиями из других систем?

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

В-третьих, разработать и отточить регламенты реагирования. Проводите регулярные учения на основе реальных сценариев. Каждый алерт должен иметь своего «владельца», а каждый инцидент — четкий путь от обнаружения до закрытия.

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