На прошедшей неделе довелось поучаствовать в качестве приглашенного эксперта в Solar CyberSprint. Одним из мероприятий здесь был киберчемпионат на киберполигоне, что и заставило меня задуматься о теме кибер- учений\соревнований\полигонов и т.п. вещах. У тех, кто долго занимается какой-то определенной деятельностью, со временем, которое измеряется ни одним десятком лет, складывается некоторое "чутье"\интуиция\"ощущение", которое сразу формирует отношение к предмету (ЕМНИП, о чем-то подобном писал Талеб в своих книжках, называя это чем-то вроде "детектор бреда"). Но, в любом случае, даже если наше "чутье" нас редко подводит, объективно разобраться в своих "ощущениях" - хорошее упражнение, поскольку, вполне возможно, что они базируются на каких-то эволюционно-наследственных принципах (а здесь я бы порекомендовал вот эту книжку), и, в современных условиях, могут быть ошибочными.
Для начала выпишем сценарии использования киберполигонов:
- Симулятор - подготовка работников SOC, прежде чем допускать к работе с реальными событиями с инфраструктур заказчиков
- Ринг - площадка для сравнительной оценки готовности подразделений SOC
- Лаборатория - искусственная среда для команды Detection engineering
Сценарий Лаборатория выглядит "притянутым за уши", а первые два, вроде бы, покрывают все возможные потребности: чтобы команда хорошо решала задачи (Симулятор), и чтобы тянулась за лучшими в отрасли (Ринг).
Для понимания, почему киберполигон плохо подходит для, казалось бы, самого подходящего сценария Симулятор, надо примерно понимать вероятность каких ошибок SOC мы хотим снижать. Во-первых, SOC может пропускать инциденты, некорректно игнорируя алерты как FP, во-вторых, SOC может ошибаться в обнаруженных инцидентах. Другие сценарии (кстати, на практике, более частые) - проблемы покрытия (не стоит сенсор, или он неправильно настроен, или не весь аудит включен, или доставка логов сломалась), проблемы ограниченности возможностей по корреляции, нехватка данных об угрозах (TI) - к киберполигонам слабо применимы, поскольку, из-за ограниченности во времени, нет возможности организовать бесконечную адаптацию детекта, да и изменений-то в искусственных инфраструктурах тоже нет, поэтому фолсе браться не откуда.
Основная проблема аналитика SOC при триаже - это понимание является ли расследуемый алерт следствием легитимного действия и поэтому он - ложное срабатывание и его надо исправлять, или он действительно - следствие инцидента. В искусственной среде киберполигона нет легитимной деятельности, поэтому все аномалии там - инциденты, которые надо публиковать, поэтому проблему ошибочного пропуска инцидента киберполигон решить не поможет, а это - наиболее частая и серьезная ошибка аналитиков. Ошибиться в расследовании обнаруженных инцидентов тоже сложно по той же причине - отсутствие легитимной активности.
Решение может показаться примитивным и простым - "подмешивать" легитимную активность в киберполигон. Но, на практике, следов легитимной активности намного-намного больше, чем следов атак, а "подмешивать" надо то, чего меньше к тому, чего больше. Поэтому, надо не в кибеполигон добавлять легальные действия пользователей, а следы атаки добавлять в реальные инфраструктуры. Искусственное добавление записей в логи не всегда просто сделать, да и на определенном уровне зрелости аналитики будут легко отличать эти вбросы, не менее эффективно, чем опытный пентестер отличит хонипот от реального сервиса. Поэтому, проще по-настоящему реализовывать какие-то сценарии атаки, но без ущерба (действительно, помимо Impact еще полно тактик, да и обнаружение на этапе Impact едва ли можно считать своевременным). Итак, мы возвратились к известному ранее red teaming-у\пентесту реальной инфраструктуры, в цели которого поставлена еще и оценка готовности SOC - как с точки зрения оперативности обнаружения, так и полноты расследования, и эффективности реагирования.
Сценарий Симулятор может быть полезен для новичков, для целей, чтобы они, в принципе, увидели как выглядят техники атакующих в консолях систем обнаружения, но, кажется, эту проблему можно неплохо решить и скриншотами в учебных материалах или сохраненными прошлыми инцидентами. Например, мы интересные инциденты обезличиваем и "прикапываем" для дальнейшего использования при онбординге новых коллег, также обезличенные инциденты иногда попадают в слайды (ну, или более новые). В общем, к сожалению, основную проблему поиска иголки в стоге сена киберполигон не решает, по причине отсутствия... стога сена.
Второй сценарий Ринг тоже не столь эффективен по той же причине отсутствия стога сена, при условии, что у всех участниках соревнований одна инфраструктура и одинаковые инструменты обнаружения и расследования. Здесь сложно пропустить (высокая критичность), так как все аномалии - инциденты, сложно не дорасследовать (средняя критичность), так как современные системы SOC свяжут по IoC-ам все релевантные события, да и вообще, все алерты, скорее всего, будут связаны с инцидентом, а оставшиеся можно досмотреть глазами все, тогда как на практике это сделать невозможно, так как событие атаки - одно на миллион легитимных событий. Получаем, что киберполигон поможет нам сравнивать команды по скорости оформления карточки инцидента - ну не самая важная задача SOC.
Киберполигон - классное, зрелищное мероприятие, но, как я пытался здесь показать, не вполне решает поставленых задач тренировки команд SOC, точнее получаемые выгоды не адекватны инвестициям в него. Команды SOC по-прежнему лучше тренировать red teaming-ом в реальных инфраструктурах. А вот для тестирования решений по безопасности киберполигон прекрасно бы подошел, за основу, для начала, можно взять сценарий MITRE Evaluation, по ходу использования, будут появляться идеи улучшений. Поскольку, на киберполигоне можно тестировать и управляемые сервисы, сценарий Ринг в этому случае автоматически реализуется тоже, ну а для самих участников - это будет прекрасный вариант Симулятора для их команд. Искренне надеюсь, что киберполигоны когда-нибудь перейдут из области маркетинга и инфоповодов, в практическую плоскость с ценностью для всей отечественной индустрии.