Считается, что злоумышленники всегда находятся на шаг впереди безопасников, развивая вредоносное ПО, техники и способы уклонения от обнаружения. Но компании-разработчики систем безопасности не отстают. Современный рынок средств защиты информации (СЗИ) насыщен разнообразными инструментами безопасности, позволяющими отреагировать на каждый шаг злоумышленника (Cyber Kill Chain), пытающегося незаконно проникнуть в корпоративную информационную систему. Эти СЗИ отвечают за генерацию соответствующих событий ИБ, которые попадают в SIEM и коррелируются по определенным правилам. Теоретически ни один шаг атакующего не должен остаться незамеченным, особенно, если мы говорим о современном SOC. Однако на практике даже использование эффективных СЗИ и настроенные правила в SIEM не гарантируют своевременное обнаружение сложной атаки.
Сергей Ненахов, эксперт группы практического анализа защищенности компании «Инфосистемы Джет»
«На сегодняшний день практически на каждой фазе сложной атаки хакерам противостоят специализированные средства защиты. Но по нашему опыту проведения пентестов и Red Teaming, а также по опыту расследования настоящих инцидентов реальность часто выглядит гораздо менее обнадеживающей, чем теоретические выкладки. Это обусловлено разными причинами: от технических особенностей до последствий “человеческого фактора“», — подтверждает эксперт группы практического анализа защищенности компании «Инфосистемы Джет» Сергей Ненахов.
Специалисты «Инфосистемы Джет» выделяют четыре глобальные проблемы, из-за которых СЗИ в SOC работают неэффективно: отсутствие правил корреляции на атаки, ошибки в логике уже реализованных правил, «слепые зоны» (Shadow IT, неподключенные сегменты и источники) и недостаток понимания атаки специалистами ИБ. Так, чтобы научиться грамотно писать правила корреляции и поддерживать их, специалисту нужно понимать суть атаки, знать возможные артефакты и идентификаторы компрометации.
Существует несколько подходов к повышению эффективности SOC. Наиболее очевидный и зачастую неизбежный — участие в расследовании реальных инцидентов, произошедших на защищаемой инфраструктуре. Но ущерб ИТ-инфраструктуре и бизнесу в целом при успешно совершенной атаке в некоторых случаях может оказаться критичным. Поэтому компании стремятся принять превентивные меры для того, чтобы проверить свой SOC на эффективность: начиная от анализа защищенности и пентестов, и заканчивая операциями Red Team и тренировками на киберполигонах. Каждый из этих методов содержит ряд нюансов.
«У каждого метода есть свои недостатки, так или иначе связанные с форматом проведения таких работ. Их объединяет одна общая сложность: невозможность выявить проблему комплексно. Например, мы провели пентест, выявили проблемы и поняли, как их исправить, внедрили некие изменения. И вроде бы всё хорошо, но впоследствии компании нужно заказывать повторный пентест. Соответственно, хорошо бы иметь некий формат, в рамках которого мы можем несколько раз итеративно проверить, действительно ли мы внедрили нужные средства защиты, правильно их настроили, и они корректно работают», — комментирует руководитель группы практического анализа защищенности компании «Инфосистемы Джет» Владимир Ротанов.
Владимир Ротанов, руководитель группы практического анализа защищенности компании «Инфосистемы Джет»
С этой целью специалисты «Инфосистемы Джет» рекомендуют использовать формат Purple Teaming. Это прогрессивный подход к тестированию SOC, в рамках которого команды Red Team и Blue Team не противостоят друг другу, а взаимодействуют. Red Team по-прежнему имитирует тактики и техники злоумышленников, но при этом фиксирует все свои действия на таймлайне и делится этими данными с Blue Team. Та, в свою очередь, используя полученные сведения, стремится как можно быстрее и эффективнее обнаружить потенциальные проблемы.
«Один из недостатков Red Teaming в том, что специалисты из Red Team, как правило, используют наиболее эффективные, сложно детектируемые и наименее “шумныеˮ техники, выбирают очень короткие Kill Chain. Получается, что Red Team провела кибероперацию, всё “поломалаˮ, подсветила проблемы, они были устранены — а через год всё начинается заново, какие-то новые векторы выявляются. Purple Teaming позволяет Red Team перед стартом провести несколько тренировок и максимально усовершенствовать мониторинг. Да, пусть это будет в открытую, и мы не сможем потренировать элемент реагирования, но это очень хорошая подготовка к Red Teaming», — добавляет старший инженер по информационной безопасности компании «Инфосистемы Джет» Евгений Вызулин.
Жизненный цикл проекта Purple Teaming включает в себя шесть основных этапов. На этапе определения угроз совместно с заказчиком определяются актуальные модели угроз (например, удаленные сотрудники), происходит выбор возможных сценариев атак.
На этапе планирования и подготовки обговариваются допустимые средства для проведения атаки и предполагаемые уязвимые места. Например, в сценарии с удаленным сотрудником это доступ в сеть, которым он пользуется. В соответствии со сценарием атака в обязательном порядке должна содержать заранее определенные техники.
На третьем этапе Red Team проводит имитацию атаки, фиксируя время запуска каждого шага и ее результаты. Blue Team проводит мониторинг и реагирование в соответствии с предоставленным ей таймлайном.
Четвертый этап заключается в анализе инцидента — оценке работы, проведенной SOC: какие атаки были зафиксированы специалистами службы ИБ, а какие нет, срабатывали ли СЗИ, почему та или иная атака не была зафиксирована.
Пятым и шестым этапом являются, соответственно, харденинг (процесс устранения найденных уязвимостей и диагностика мониторинга) и повторная проверка. В рамках перепроверки специалисты должны убедиться в том, что изменения внесены корректно.
Ключевым компонентом Purple Teaming, таким образом, является таймлайн-фактор, на основе которого строится взаимодействие Red Team и Blue Team.
«Таймлайн нужен для взаимодействия команд и, в частности, для того, чтобы команда защитников могла как можно быстрее найти события, связанные с проведенными атаками. Поэтому таймлайн обязательно должен включать в себя время запуска той или иной техники или атаки, адреса источников и назначения атаки, а также любую дополнительную информацию, которую Red Team посчитает нужным сообщить, чтобы эффективнее отсортировать события в SIEM», — поясняет Сергей Ненахов.
Purple Teaming позволяет команде SOC решить все перечисленные выше проблемы. Например, при изначальном отсутствии в SIEM правил корреляции на конкретную атаку Blue Team не видит инцидента. Но в SIEM фиксируются события, которые сортируются благодаря таймлайну, определяются маркеры атаки и пишутся новые правила для них.
Purple Teaming помогает специалистам SOC выявить даже те проблемы, которые связаны не с настройкой мониторинга или действиями сотрудников, а с ограничениями вендора.
«Так, на одном из наших проектов весь мониторинг был настроен “по фэншуюˮ, не было никаких внешних ошибок — но одни и те же атаки в системе то отлавливались, то не отлавливались. После проведенного Purple Teaming оказалось, что в конкретном SIEM вендор установил ограничения, включающиеся при превышении обозначенного в лицензии порогового значения по числу обрабатываемых событий в секунду. Все события, которые превышали этот порог, просто отбрасывались и не анализировались», — рассказывает Сергей Ненахов.
Purple Teaming обеспечивает максимальное покрытие по техникам атак на всех этапах Kill Chain. На этапе подготовки атаки все эти техники обговариваются. Таким образом, когда команда атакующих выполняет работу по таймлайну, она следует четкому сценарию и может проверить действие всех необходимых инструментов и методик.
Purple Teaming — это единственный формат, в рамках которого Blue Team и Red Team работают в коллаборации, что способствует расширению практических навыков команды безопасников.
Данный формат, помимо прочего, предусматривает для специалистов большую гибкость. Например, если на каком-то этапе они понимают, что все типовые атаки уже были зафиксированы, Red Team может начать использовать более скрытые и продвинутые техники.
«На реальных проектах может возникнуть ситуация, когда у заказчика недостаточно ресурсов, чтобы выделить отдельных сотрудников SOC, полностью занятых в Blue Team. В таких случаях у нас есть возможность привлечь на проект сотрудников своего SOC — аналитиков и специалистов по расследованию инцидентов. Соответственно, в роли Blue Team выступит наша команда, которая подключится к SIEM, будет реагировать на атаки Red Team и по итогу составит рекомендации для заказчика о том, как можно исправить выявленные недостатки», – комментирует Сергей Ненахов.