Введение

Как помочь растормошить команду 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-команды, с чем может помочь в том числе проведение пентеста.

Регулярное тестирование на проникновение обеспечит ситуационный центр новыми, живыми кейсами и поможет обучить текущую команду аналитиков работе с инфраструктурой того заказчика, которого они защищают.