Оценка зрелости центров мониторинга

Первая статья цикла посвящена покрытию мониторингом ИТ-инфраструктуры. В обоих случаях, о которых речь пойдет ниже, компании решили строить внутренний SOC: за мониторинг и реагирование на киберинциденты отвечали собственные сотрудники, а к услугам внешнего провайдера прибегали только при проведении расследований.

Кейс 1. Мониторинг только критически важных активов

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

В ходе мониторинга на одном из активов благодаря EDR-решению была выявлена попытка удаленного исполнения кода – использовались скрипты из фреймворка Impacket. Как правило, он применяется для горизонтального перемещения в скомпрометированной сети и свидетельствует об активности злоумышленника (или действиях специалиста по анализу защищенности). То есть, SOC обнаружил инцидент, когда атакующие уже достигли критически важного актива, так как его дельта-окрестность (элементы, окружающие актив) не была подключена к мониторингу. Расследование с привлечением внешних экспертов показало, что она была скомпрометирована.

Проблема заключается еще и в том, что при таком подходе аналитики могут неправильно оценить серьезность ситуации и предпринять ошибочные действия: заблокировать учетную запись, изолировать хост и т. д. При этом в отсутствие событий от других источников не получится глубоко проанализировать первопричины инцидента. Каким образом вредоносное ПО вроде Impacket попало на сервер? Почему злоумышленник обладает действительной учетной записью? Ответы на эти и другие вопросы помогли бы правильно нейтрализовать вектор проникновения. Если действовать ошибочно, киберпреступник поймет, что обнаружен, быстро перестроится, выберет другой способ атаки либо, например, зашифрует важные данные для последующего шантажа. Шансы на реагирование без последствий в такой ситуации резко уменьшатся.

Поэтому важно расширять зону мониторинга – включать в нее не только критические активы, но и их дельта-окрестность. Такой подход позволяет:

• увеличить число точек выявления;
• повысить вероятность обнаружения угроз на начальной стадии;
• создать запас времени, чтобы выбрать оптимальный метод реагирования.

Кейс 2. Подключение максимального количества источников

Другая компания, напротив, подключила к SIEM-системе все возможные источники событий и установила EDR-агенты на все серверы и рабочие станции, на которых это было возможно. Таким образом, центр мониторинга собирал максимальное количество событий.

Однако такой подход привел к пропуску важного инцидента среди огромного потока незначимых событий.

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

Избежать этого можно, если оценивать подключение каждого источника в контексте решаемых задач. То есть нужно понимать, какие правила обнаружения могут быть реализованы по событиям от конкретного источника. Это позволит разделить источники на обязательные для подключения и те, полезность подключения которых под вопросом.

Источники, обязательные для подключения, характеризуются:

• широкой зона охвата инфраструктурных событий;
• простотой и скоростью подключения;
• покрытием значительной части матрицы MITRE ATT&CK.

А признаками источников с низкой практической ценностью, напротив, являются:

• невозможность эффективного обнаружения ключевых техник MITRE ATT&CK;
• возможность реализации сценариев обнаружения исключительно в специфичном бизнес-контексте;
• отсутствие реального влияния на динамику текущих событий в системе.

Рациональный подход

Важно понимать, что оценка уровня покрытия инфраструктуры не должна восприниматься как единоразовая задача. Это непрерывный процесс, который должен включать как минимум регулярные проверки следующих показателей:

• количество подключенных к SIEM источников;
• покрытие конечных устройств EDR-агентами (например, с помощью BI.ZONE EDR);
• охват сетевого пространства и точек сопряжения средствами анализа трафика;
• уровень покрытия других элементов инфраструктуры.

Чтобы автоматизировать процесс идентификации объектов, которые не покрыты мониторингом, применяются специализированные решения, такие как IRP или SOAR (например, BI.ZONE SOAR). Подобные платформы собирают сведения обо всех активах и сопоставляют их с реально подключенными к SOC источниками. Полученные данные помогают аналитикам сформировать исчерпывающее представление об инциденте и предпринять точные и эффективные действия для реагирования.

Реклама.: ООО "БИЗон". ИНН 9701036178. Erid: 2SDnjbyi4eJ

Во втором материале цикла расскажем о ключевой функции SOC – обнаружении угроз и киберинцидентов, ради которой и организуется постоянный мониторинг безопасности. Без эффективного обнаружения угроз все остальные процессы в рамках SOC лишены смысла. От чего же зависит эффективность обнаружения?

SOC работает круглосуточно или не работает вообще

Одна из первых и ключевых задач при создании SOC – организация команды и режима работы. Без правильно выстроенного графика невозможно обеспечить непрерывный мониторинг. SOC по определению должен функционировать в режиме 24/7. Именно это обеспечивает своевременное обнаружение угроз и реагирование на инциденты.

Непрерывность мониторинга имеет критически важное значение, поскольку атаки могут происходить в любой момент: ночью, в выходные и праздничные дни. Согласно статистике BI.ZONE, более половины критических киберинцидентов происходят в нерабочее время. Попытка запустить SOC в режиме 8/5 сводит его эффективность к минимуму, а любая задержка в реагировании может обернуться серьезными последствиями.

Даже в случае использования модели MSSP SOC, в компании должна быть организована внутренняя дежурная смена. Она необходима для оперативного взаимодействия с внешним провайдером, принятия управленческих решений, эскалации инцидентов, а также координации действий внутри компании, когда реализуются сценарии реагирования.

MSSP обеспечивает мониторинг и первичную обработку, но ответственность за активное реагирование, внутреннюю готовность к инцидентам и принятие решений лежит на владельце ИТ-инфраструктуры. На практике важность этого требования часто недооценивают или игнорируют. Это приводит к задержкам в реагировании и росту потенциального ущерба от инцидентов.

Слепые зоны: кто действительно видит злоумышленника?

Штатных подсистем аудита часто недостаточно, чтобы эффективно обнаруживать киберугрозы. Причина – ограниченная глубина видимости и контекста. В дополнение нужно использовать решения класса NTA. Они позволяют выявлять подозрительные паттерны на уровне сети, которые могут не фиксироваться в других типах событий, например атаки на сетевые протоколы или использование скрытых каналов коммуникации вредоносного ПО.

Еще один важный инструмент – EDR-решения. Они поставляют подробную телеметрию с конечных точек, на которых злоумышленник непосредственно выполняет свои действия. Системы EDR обеспечивают не только глубокую видимость, но и предоставляют инструменты активного реагирования на уже обнаруженные киберинциденты.

Оперативное обнаружение сложных и скрытых атак штатными подсистемами аудита без NTA и EDR зачастую невозможно. Только совместное использование всех трех источников данных для мониторинга позволяет построить эффективную систему обнаружения и реагирования, а также поддерживать процесс проактивного поиска угроз – Threat Hunting.

Логика обнаружения без TI – догадки вместо защиты

Эффективность обнаружения в первую очередь определяется качеством и полнотой детектирующей логики, которой располагает SOC. Разработка детектирующего контента начинается с понимания, какую именно вредоносную активность необходимо выявлять. Подробнее о процессе разработки детектирующей логики можно прочитать в отдельной статье [1].

Несмотря на кажущуюся универсальность ландшафта угроз, на практике он сильно варьируется. Опыт компании BI.ZONE, которая работает с заказчиками из разных стран и отраслей, доказывает, что и география, и сфера деятельности напрямую влияют на характер угроз, с которыми сталкивается организация. Наличие собственной киберразведки (Threat Intelligence, TI) в SOC позволяет получить релевантную информацию об угрозах в контексте конкретной организации, отрасли, территориальной принадлежности. А это, в свою очередь, помогает приоритизировать разработку детектирующих правил.

TI – это не только индикаторы компрометации (IoC), но и информация о тактиках, техниках и процедурах (TTP) атакующих. Именно TTP в первую очередь являются тем источником данных, которые нужны, чтобы приоритизировать разработку правил корреляции. А индикаторы компрометации помогают реагировать на уже известные угрозы: поток поступающих событий проверяется на наличие IoC. Без использования киберразведки есть риск создавать контент и правила обнаружения на основе нерелевантных или устаревших угроз. Это снижает эффективность защиты, приводит к ложным срабатываниям или пропуску реальных атак.

Оптимизация SOC: укрощение алертов

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

В BI.ZONE мы постоянно внедряем новые механизмы автоматизации, используя МО и ИИ, чтобы повысить эффективность работы. Среди таких решений алгоритм автоназначения алертов аналитикам, механизм выявления флуда правил, модель автоматического закрытия повторяющихся или схожих алертов, а также ассистент, объясняющий содержимое командной строки в Сейчас порядка 35% алертов в сервисе BI.ZONE TDR обрабатывается автоматизированно.

1. https://bi.zone/expertise/blog/kak-obespechit-effektivnuyu-logiku-obnaruzheniya-ugroz-v-soc 

На правах рекламы. ООО "БИЗон". ИНН 9701036178. Erid: 2SDnjdzojyp