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