Польза от Pentest для постинцидента
Введение
Как помочь растормошить команду SOCа и заставить их бороться против настоящего, а не вымышленного злоумышленника? С чем чаще всего связана некоторая халатность в отношении процесса постинцидента и как это влияет на процесс расследования в целом?
От чего в наибольшей степени будeт зависеть этап подготовки к расследованию и само расследование? Сегодня мы рассмотрим взаимосвязь пентеста для компании и процессов Lessons Learned.
Некоторые аутсорс-SOC подмечают, что для команды blue team необходим какой-то стимул или обучение для того, чтобы аналитики были готовы к неожиданным и редким инцидентам. Потому как текучка — это знакомо, актуально практически для всех и по возможности автоматизировано и заскриптовано в плейбуках.
Проблемы обычно возникают тогда, когда или не проработана часть инфраструктуры (она и атаки на нее остаются незнакомыми), или когда команда, даже поднатаскавшись на типовых кейсах определенного направления, пасует перед настоящей задачей. Причина последнего нередко в том, что результаты учений не были грамотно использованы дальше.
В чем вообще цель работы над ошибками: в том, чтобы изменить что-то вокруг или поменять свой подход к работе?
Типовая работа коммерческого SOC
Если представить сферический SOC в вакууме, кто-нибудь скажет о том, что это стандартные услуги по отработке инцидентов, стандартные инциденты и плейбуки. Если вы хоть раз строили кому-то SOC (или делали его для себя), возможно, вы застали этот момент, когда команда внедрения смотрит и в стандарты, и в наработки по теме, чтобы с минимальными усилиями адаптировать под реалии заказчика какие-то классические кейсы. Нестандарт начинался тогда, когда специалисты вендора уже ушли, а настоящие атаки только стартовали.
За последнее время эта картина несколько изменилась — теперь есть и полноценный аудит, и best practice стали шире, теперь они могут включать в себя не такой популярный ранее антифрод, отдельным направлением стоят АСУ ТП и так далее.
Неизменно одно — по словам некоторых экспертов на том же SOC Forum, red team и blue team почему-то ничего не находят или находят какие-то вырожденные или слишком простые кейсы. От которых или нужно было защититься еще десять лет назад, или такой сценарий в принципе не может прийти никому в голову.
Кругозор обеих команд упирается в свои же наработки и не расширяется дальше. Но почему?
Есть несколько способов принести команде новую экспертизу — это учения, круглые столы и пентесты. Возможно, у вас используется что-то еще — например, вы регулярно читаете dfir-отчеты или мониторите отчеты по атакующим.
Но как быть дальше, когда все эти необходимые мероприятия проведены? Как не вернуться к исходной точке? Для этого существует целый этап в расследовании — постинцидент, и в нем нужно уметь работать грамотно.
Что такое Lessons Learned и зачем это делается?
Как проходит постинцидент? По итогам конкретных ситуаций после разбора проводятся работы над инфраструктурой и над планами реагирования, формируются планы по улучшению самого процесса реагирования и расследования. Итогом данного этапа становится оптимизация текущих процессов и улучшенная подготовка аналитиков, более систематизированный подход к дальнейшей «работе над ошибками».
Данный процесс включает в себя следующие этапы:
· Идентификация проблем и сильных сторон, сбор комментариев и рекомендаций
· Документирование всех находок
· Анализ и подготовка документации
· Формирование базы знаний
· Дальнейшее использование собранных данных
Цели постинцидента чаще всего следующие:
· Учиться на ошибках — не повторять действий, которые не принесли положительного результата
· Понять проблемы как в инфраструктуре, так и организационные
· Подчеркнуть успех текущих мер — не забывать о том, что было сделано хорошо
· Сохранение знаний в документации — само наличие базы знаний по частым проблемам и выходам из них помогает наладить процессы
· Уменьшение риска возникновения проблем в дальнейшем — скорее всего, часть рисков будет митигирована сменой подхода
· Улучшение производительности — скорость реагирования и натаскивание на решение задач
Откуда приходит контент?
Конечная цель работы SOC всегда заключается в повышении уровня защищенности, а не в периодическом закрытии метрик и отбитии пентеста время от времени. Компания и ее системы должны быть надежно защищены и постоянно контролироваться, люди должны быть подготовлены к любому сценарию атаки.
Постинцидент как раз и приводит безопасность по спирали к целевой защищенности. Существует несколько уровней зрелости постинцидентого процесса:
В зависимости от того, как часто и над сколькими инцидентами проведены Lessons Learned, меняется итоговая картина доработок для SOC-процессов. В частности, в сертификации GIAC Certified Incident Handler упоминается, что даже в случае, если в результате постинцидента какие-то проблемы и были выявлены, они редко передаются на фазу подготовки в следующем процессном цикле. Также люди могут пренебрегать внесениями изменений в документацию перед непосредственной работой, даже если какие-то результаты и были получены.
То есть процесс, который проходит где-то параллельно от ежедневной деятельности аналитики, непредсказуем, его результатами трудно воспользоваться. Часто вообще в SOC могут пренебречь этой фазой, потому что после завершения одного инцидента требуется перейти к следующему, и к следующему, и здесь нет времени на проработку своих возможных ошибок.
Отношение к процессу
· Восприятие процесса как необходимости
· По возможности облегчать заполнение форм для пользователя
· Регулярная проверка и пересмотр данных
· Использование накопленных данных в работе
Существуют целые методики того, как работать с оптимизацией в Lessons Learned, как пример рассмотрим одну из них.
Три фазы работы с LL и анализом
При такой работе с результатами инцидентов принятые меры в ходе постинцидента фиксируются, а инциденты тегируются; далее эти результаты разбиваются по группам в зависимости от типа инцидента, критичности и иных метрик. На выходе можно получить картину того, какие инциденты были дорасследованы после закрытия, какие меры имели положительный, а какие — отрицательный эффект. Также фиксируется необходимость изменения мер в каждой группе инцидентов: необходимость доработки плейбука, добавления в него новых шагов, необходимость дополнительной подготовки аналитиков.
Результатами такой обработки служат выводы — что нужно перестать или начать делать, нужны ли изменения вообще. На выходе мы собираем полноценную базу наработок с контекстом решенных и нерешенных проблем.
Откуда мы можем получить контекст? То есть тот набор инцидентов, которые позволили бы эффективно протестировать существующие плейбуки и готовность аналитиков.
Проведение пентеста, о котором может не знать SOC
Непредсказуемость пентеста без участия blue team обеспечивает по итогу более широкий кругозор для команды SOC-аналитиков. Если не пытаться в моменте что-то подстраховать и скомпенсировать, видна будет реальная картина уровня защищенности, исключается возможность предварительной договоренности и перераспределения сил, например, на веб-защиту, если атаковать планируется именно в этом направлении.
Первостепенной целью пентеста, если верить независимым исследователям, являются ошибки в бизнес-логике. Уязвимости бизнес-логики могут включать в себя ошибки в процессах, правилах и рабочих потоках, которые могут быть использованы злоумышленниками для несанкционированного доступа, манипуляции данными или нарушения работы.
Почему недостаточно классического запланированного пентеста
· «Строители инфраструктуры» делают в общей своей массе те же ошибки со временем, которые приводят к типовым уязвимостям и рискам. Это можно выявить и без пентеста
· Автопроверки внутри продукта не дадут полного покрытия, так как не рассматриваются нестандартные кейсы
· У хорошего пентеста нет такого понятия как out of scope, даже если заказчик не относится к определенной сфере, например банки или телеком, всё равно стоит попробовать на нем сценарии и из этих сфер тоже
· У пентеста и у ИБ зачастую разные цели проверки продуктов, сети, защищенности Команда защиты заинтересована в том, чтобы доказать на реальном примере результаты своей хорошей работы, и реже — в том, чтобы найти свои слабые места
Что считать мерилом успеха?
Повышение готовности к редким кейсам после пентеста — один из бонусов независимых исследований. Также результатом может стать проверка на прочность не только навыков аналитиков, но и средств защиты — мало ли, может, пришла пора их заменить?
На самом деле, получение в результате пентеста подтверждения того, что заказчик защищен не самым лучшим образом, в какой-то мере даже хорошо — лучше так, чем с реальным злоумышленником. Неожиданный пентест без договоренностей, который беспристрастно проверяет всё, что может найти, обеспечит и встряску для аналитиков, и новый контекст для постинцидента.
Именно на этап Lessons Learned после проведения проверки и стоит потратить драгоценное время, перенести новые подсвеченные риски в документацию и внедрить в этап подготовки.
Итоги
В постоянной гонке за показателями внутри SOC нередки случаи тщательной проработки тех вопросов, которые не являются актуальными для компании. Помимо того, чтобы с должной серьезностью относиться к этапу постинцидента, также требуется регулярная корректировка вектора внимания SOC-команды, с чем может помочь в том числе проведение пентеста.
Регулярное тестирование на проникновение обеспечит ситуационный центр новыми, живыми кейсами и поможет обучить текущую команду аналитиков работе с инфраструктурой того заказчика, которого они защищают.
