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

Изоляция: за и против Когда аналитик SOC определяет, что случился боевой инцидент, первым шагом становится блокировка. Это ком- плекс мер, направленных на то, чтобы немедленно остановить вредоносную активность. Часто первоочередной мерой является изоляция. Изоляция может быть применена как применительно к отдельным хостам, так и на уровне сетевых сегментов, в зави- симости от того, какие активы оказались под ударом. Если вредоносная актив- ность обнаружена на конкретном хосте, то логично изолировать его для даль- нейшего анализа. Однако при этом важно в первую очередь пресечь рас- пространение угрозы. Использование систем класса EDR значительно упрощает и ускоряет изо- ляцию. Они позволяют централизованно управлять агентами на хостах через консоль. Например, аналитик заметил на хосте вредоносную активность, под- тверждающую инцидент, и мгновенно изолировал его, сохранив лишь связь с консолью управления EDR. При этом доступ в Интернет и локальную сеть для хоста отключается. Стоит оговориться, что подобные инструменты значительно упрощают рабо- ту аналитика, но если они отсутствуют, все равно в наличии должны быть необхо- димые доступы и полномочия для выпол- нения изоляции. В крайнем случае SOC может обращаться к администраторам инфраструктуры для отключения, хотя этот сценарий не такой быстрый. Существует и обратная сторона изо- ляции: если инцидент имеет низкую сте- пень критичности, а изоляция системы принесет больше ущерба, чем вред, нанесенный самим инцидентом, то здесь аналитик должен тщательно взвесить все "за" и "против". Например, когда речь идет о критически важной системе, которую нельзя остановить, потребуется более гибкий подход: можно попробо- вать блокировать только те процессы, которые были замечены в подозритель- ной активности, или избирательно закрыть определенные порты, по кото- рым идет связь с центром управления вредоносного ПО. И хотя это требует творческого подхо- да и глубокого анализа ситуации, в конечном счете основная цель – изо- ляция для последующего расследования и анализа угрозы. Однако важно отметить, что полностью автоматический ответ на инциденты, скорее всего, неэффективен. Системы, которые помогают аналитику принимать решения, указывая на оптимальные дей- ствия, очень полезны, но окончательное решение все же должно оставаться за человеком. ИТ-отдел, ты за меня или за медведя? Во многих практический кейсах про- слеживается скрытое противоборство между командами информационной без- опасности и ИТ-отделами. ИТ-специали- сты, как правило, заинтересованы в том, чтобы инцидент был устранен немед- ленно по тем фактам, которые известны в моменте, добавить индикаторы ком- прометации, прописать новые правила в системах защиты и забыть об инци- денте до его возможного повторения. ИБ-специалисты же, напротив, стремятся как можно дольше исследовать развитие атаки, чтобы получить максимальное количество информации. Для полноцен- ного расследования требуется время, чтобы проследить действия злоумыш- ленника и понять его дальнейшие шаги. В этом есть логика, ведь если анализ атаки завершить исследованием только скомпрометированного актива, то можно упустить ключевые детали: так и оста- нется неизвестным, какой была точка проникновения в инфраструктуру, какие цели преследовал злоумышленник и где еще он успел закрепиться. Допустим, с зараженного хоста вредоносное ПО будет удалено, но где оно уже успело распространиться по сети – об этом уже можно и не узнать. И здесь начинается следующий этап реагирования: после устранения основ- ной угрозы следует провести тщатель- ный анализ в ближайшем окружении пораженного актива на предмет воз- можных компрометаций. В него могут включаться анализ сетевых журналов, чтобы понять, куда обращался хост в последнее время, и поиск признаков проникновения на других устройствах. Например, можно искать идентичные файлы по хэшам, которые уже были обнаружены на зараженном хосте, а также проверять наличие подозри- тельных задач, специфических учетных записей и любых иных аномалий. Совсем недавно мне попался случай, который наглядно показал эту проблему. Вредоносное ПО закрепилось на одном из хостов и уже успело слить данные из контроллера домена. Однако оно также затерло все журналы, скрывая следы своей активности. Аналитикам удалось выявить скомпрометированные активы на периметре и расширить область ана- лиза, но точка первоначального проник- новения так и осталась загадкой. Без журналов или иных данных провести пол- ноценное расследование и выявить источ- ник стало невозможно – вот еще одна трудность в этом противостоянии между оперативностью и глубиной анализа. Умный SIEM не отменяет прямолинейного лог-менеджмента Лог-менеджмент как система хранения и обработки логов по своей структуре проще в сравнении с SIEM, но за счет 22 • СПЕЦПРОЕКТ Зарисовки о реагировании на инциденты в SOC UserGate сновная задача SOC – своевременно обнаруживать и нейтрализовывать инциденты, предотвращая их дальнейшее распространение и минимизируя ущерб для бизнеса. Однако процесс реагирования требует не только высоких профессиональных навыков специалистов, но также инструментария и четкого алгоритма действий, выработанного специально для каждой инфраструктуры. Рассмотрим несколько аспектов реагирования на инциденты из опыта SOC UserGate. О Дмитрий Шулинин, руководитель SOC UserGate Фото: UserGate