660 правил на SIEM за два дня! (Реальность или Утопия)

Недавно наша команда "KCELL" участвовала в киберучениях на стороне Blue Team. В первой серии учений от ГТС, прошедших 19-20 августа, мы использовали SIEM Splunk. Однако не всё было так гладко, как хотелось бы: о том, какая SIEM нас ждёт, мы узнали всего за неделю до старта, а доступ к системе получили за 4 дня до соревнований.

Что такое SIEM?

SIEM (Security Information and Event Management) — это система управления информацией и событиями безопасности, которая собирает, анализирует и коррелирует события в ИТ-инфраструктуре, помогая выявлять потенциальные угрозы и инциденты. Обычно внедрение и настройка SIEM могут занимать месяцы, а то и годы, чтобы достичь максимальной эффективности. Но у нас было всего 4 дня — и это делало задачу ещё интереснее.

Теория: от отсутствия правил до автоматизации

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

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

Практика: автоматизация — наш главный друг

Если вы ищете готовое решение, все скрипты и датасеты доступны на нашем GitHub. Основную часть корреляционных правил мы сгенерировали с помощью скрипта, чтобы сэкономить время.

Основная идея заключалась в том, чтобы детектировать потенциально вредоносные команды через консоль на машинах, основываясь на GTFObins для Linux и LOLbins для Windows. Затем мы выгрузили все команды и отфильтровали их от шаблонных примеров — процесс, который частично автоматизировали, частично делали вручную. Все готовые датасеты, использованные нашей командой, уже доступны на репозитории.

Следующим шагом было создание правил на основе датасета и их импорт в локальную SIEM Splunk. Однако, сама Splunk не поддерживает импорт правил "из коробки", поэтому пришлось использовать API для написания автоматизированного скрипта на Python. После этого мы занялись оптимизацией правил, исключая ложные срабатывания с помощью нашей Red Team, проводившей тестирование в локальной сети. Когда правила были оптимизированы, мы перенесли их на SIEM, использовавшуюся в соревнованиях, что также потребовало отдельного скрипта.

Итак, после нескольких бессонных ночей наша команда смогла достичь достойного результата на учениях от ГТС.

Следующий вызов: киберучения от ЦАРКА

В рамках конференции KazHackStan прошли соревнования на киберполигоне CyberKymbez, где команды Red Team должны были атаковать системы, захватывая инфраструктуру и SCADA. В этом году впервые участвовали и команды Blue Team. Основное отличие — новая SIEM ELK, масштаб инфраструктуры увеличился в три раза, а атакующих стало в пять раз больше.

Мы продолжили подготовку по схожей схеме: развернули у себя аналогичную SIEM, настроили логирование и попросили Red Team атаковать нас для последующей работы с логами. Опыт, полученный на учениях от ГТС, помог нам оптимизировать процесс работы с False Positive и подготовиться к новым вызовам. Однако полной информации о структуре и сервисах киберполигона у нас не было, что осложняло задачу.

Доступ к инфраструктуре соревнований мы получили только в первый день, одновременно с командами Red Team. Это означало, что настройка SIEM проходила "на лету", при этом нас одновременно атаковали 125 машин. Тем не менее, скрипты помогли нам автоматизировать процесс добавления правил, а мы параллельно занимались их тюнингом.

К середине второго дня нам удалось минимизировать шум от ложных срабатываний и сосредоточиться на написании правил для фиксации "недопустимых событий". Эта тактика позволила нам фиксировать атаки и получать дополнительные баллы за обнаружение нарушений в реальном времени.

Итоги

Автоматизация ключевых процессов помогла нам сэкономить время и эффективно подготовиться к киберучениям. Надеемся, что наш опыт будет полезен для вас. Помните: coffee, code and repeat!