Журнал "Information Security/ Информационная безопасность" #3, 2025

Первая статья цикла посвящена покрытию мониторингом ИТ-инфраструк- туры. В обоих случаях, о которых речь пойдет ниже, компании решили строить внутренний SOC: за мониторинг и реа- гирование на киберинциденты отвечали собственные сотрудники, а к услугам внешнего провайдера прибегали только при проведении расследований. Кейс 1. Мониторинг только критически важных активов В первом случае компания исходила из того, что защищать нужно только крити- чески важные активы. Поэтому к монито- рингу были подключены лишь отдельные приложения, серверы и рабочие станции, которые имели принципиальное значение для бизнес-процессов. Еще одним аргу- ментом в пользу такого подхода стало желание снизить расходы, связанные с покупкой лицензий на СЗИ, хранением данных и т. д. Причем у критически важных активов оставалось прямое сопря- жение с другими ресурсами компании. В ходе мониторинга на одном из акти- вов благодаря EDR-решению была выявлена попытка удаленного исполне- ния кода – использовались скрипты из фреймворка Impacket. Как правило, он применяется для горизонтального пере- мещения в скомпрометированной сети и свидетельствует об активности злоумыш- ленника (или действиях специалиста по анализу защищенности). То есть, SOC обнаружил инцидент, когда атакующие уже достигли критически важного актива, так как его дельта-окрестность (элемен- ты, окружающие актив) не была под- ключена к мониторингу. Расследование с привлечением внешних экспертов пока- зало, что она была скомпрометирована. Проблема заключается еще и в том, что при таком подходе аналитики могут неправильно оценить серьезность ситуа- ции и предпринять ошибочные действия: заблокировать учетную запись, изолиро- вать хост и т. д. При этом в отсутствие событий от других источников не полу- чится глубоко проанализировать перво- причины инцидента. Каким образом вре- доносное ПО вроде Impacket попало на сервер? Почему злоумышленник обладает действительной учетной записью? Ответы на эти и другие вопросы помогли бы пра- вильно нейтрализовать вектор проникно- вения. Если действовать ошибочно, кибер- преступник поймет, что обнаружен, быстро перестроится, выберет другой способ атаки либо, например, зашифрует важные данные для последующего шантажа. Шансы на реагирование без последствий в такой ситуации резко уменьшатся. Поэтому важно расширять зону мони- торинга – включать в нее не только кри- тические активы, но и их дельта-окрест- ность. Такой подход позволяет: l увеличить число точек выявления; l повысить вероятность обнаружения угроз на начальной стадии; l создать запас времени, чтобы выбрать оптимальный метод реагирования. Кейс 2. Подключение максималь- ного количества источников Другая компания, напротив, подключи- ла к SIEM-системе все возможные источ- ники событий и установила EDR-агенты на все серверы и рабочие станции, на которых это было возможно. Таким образом, центр мониторинга собирал максимальное количество событий. Однако такой подход привел к пропуску важного инцидента среди огромного потока незначимых событий. Выяснилось, что источники подключа- ли к мониторингу без анализа целесо- образности подключения. Компания также не оценивала, какие именно типы событий важно собирать, какие задачи мониторинга они позволяют решать. Все это привело не только к пропуску инци- дента, но и к необоснованному росту расходов на содержание SOC. Избежать этого можно, если оценивать подключение каждого источника в кон- тексте решаемых задач. То есть нужно понимать, какие правила обнаружения могут быть реализованы по событиям от конкретного источника. Это позволит разделить источники на обязательные для подключения и те, полезность под- ключения которых под вопросом. Источники, обязательные для под- ключения, характеризуются: l широкой зона охвата инфраструктур- ных событий; l простотой и скоростью подключения; l покрытием значительной части мат- рицы MITRE ATT&CK. А признаками источников с низкой прак- тической ценностью, напротив, являются: l невозможность эффективного обна- ружения ключевых техник MITRE ATT&CK; l возможность реализации сценариев обнаружения исключительно в специ- фичном бизнес-контексте; l отсутствие реального влияния на динамику текущих событий в системе. Рациональный подход Важно понимать, что оценка уровня покрытия инфраструктуры не должна восприниматься как единоразовая зада- ча. Это непрерывный процесс, который должен включать как минимум регуляр- ные проверки следующих показателей: l количество подключенных к SIEM источников; l покрытие конечных устройств EDR- агентами (например, с помощью BI.ZONE EDR); l охват сетевого пространства и точек сопряжения средствами анализа трафика; l уровень покрытия других элементов инфраструктуры. Чтобы автоматизировать процесс идентификации объектов, которые не покрыты мониторингом, применяются специализированные решения, такие как IRP или SOAR (например, BI.ZONE SOAR). Подобные платформы собирают сведения обо всех активах и сопостав- ляют их с реально подключенными к SOC источниками. Полученные данные помогают аналитикам сформировать исчерпывающее представление об инци- денте и предпринять точные и эффек- тивные действия для реагирования. l 58 • СПЕЦПРОЕКТ Покрытие мониторингом ИТ-инфраструктуры: как выбрать оптимальный уровень омпания BI.ZONE совместно с журналом “Информационная безопасность” запускает цикл публикаций о ключевых аспектах функционирования SOC. И при строительстве собственного центра мониторинга, и при взаимодействии с внешним провай- дером (MSSP) организации могут допустить ошибки, которые повлияют на эффективность защиты. Эксперты подробно разбе- рут семь направлений работы SOC, а также расскажут о рас- пространенных проблемах, с которыми сталкиваются компании. К Марсель Айсин, руководитель BI.ZONE SOC Consulting Фото: BI.ZONE На правах рекламы.: ООО "БИЗон". ИНН 9701036178. Erid: 2SDnjbyi4eJ