Тестирование на проникновение и red teaming, или любой другой security assessment\анализ защищенности вообще - наиболее эффективный способ проверки как технической защищенности информационных систем, так и оперативной готовности подразделений SOC. В этой связи идея Continuous pentest\непрерывного пентеста может быть подходящим решением. Смысл здесь в том, что есть некоторое внутреннее подразделение, которое постоянно проводит какие-либо offensive-мероприятия, а команда, вовлеченная в мониторинг и DFIR не в курсе и их задача своевременно обнаружить и предотвратить развитие атаки.
Современные человекоуправляемые атаки крайне похожи на пенест. Различия в поведении, конечно, есть, например, однако, заметить эти различия необходимо не слишком поздно. Поэтому, в условиях продуктивных инфраструктур, надо иметь возможность однозначно и быстро дать ответ является ли выявленная активность следствием работы аудиторов или реальной атакой. В практике встречались ситуации, когда реальную атаку некорректно интерпретировали как аудит из-за того, что, действительно, в это же время проводился пентест. В целом, сам факт параллельного анализа защищенности - замечательное прикрытие для реальной атаки, поскольку при плохой организации работ при анализе защищенности, аудит и атака неотличимы. Риск пропуска реальной атаки по причине проведения пентеста действительно велик, тем более, если пентест ведется непрерывно, - это и является основной мотивацией для написания мною этой статьи.
Для возможности быстрой идентификации реальной атаки требуется соблюдение двух условий. Первое - регламентированность работы подразделений ИТ - это всегда полезно, так как является основой для эффективного обнаружения аномалий. Ну, например, с админскими полномочиями должны подключаться только с выделенных АРМ, а эти подключения должны быть подкреплены официальным обращением в ИТ-поддержку, да и вообще, лучше подключаться с минимальными правами, следуя принципу минимума полномочий. Второе - регламентированность работ аудиторов - это уже относится непосредственно к нашему непрерывному пентесту. Для однозначной атрибуции пентеста работа аудиторов должна быть регламентирована и спланирована, а все действия и IoC-и аккуратно задокументированы - только так можно исключить интерференцию с реальной атакой. Также должно быть однозначно определено взаимодействие красной и синий команд, как минимум, чтобы не тратить время на выяснение отношений.
Немаловажным моментом является минимизация нагрузки на SOC при проведении внутренних учений. Действительно, постоянные военные учения - замечательная вещь, но они не должны подрывать боеспособность армии. Так и в нашем случае, чрезмерная загрузка команды SOC внутренним постоянным пентестом не должна приводить к ресурсному истощению и, как следствие, пропуску инцидентов.
Далее в статье я предложу пункты в Регламент проведения непрерывного анализа защищенности, где, на мой взгляд, соблюдается баланс между результативностью непрерывного пентеста, снижение риска интерференции с реальной атакой, и минимизация нагрузки на команду SOC.
Регламент проведения внутреннего анализа защищенности
0. Стороны взаимодействия
0.1 Команда SOC - выполняет непрерывный мониторинг и DFIR
0.2 Красная команда (КК) - выполняет непрерывный анализ защищенности
0.3 Заказчик - получает инциденты от SOC, одновременно является заказчиком работ КК
1. Подготовка
1.1. До начала работ КК составляется план работ. Детализация плана – достаточная для атрибуции любой подозрительной активности в сети к работе КК и невозможности ошибочной атрибуции реальной атаки к работе КК. Описание содержит, насколько это возможно, все артефакты (АКК), и состав исполнителей.
1.2. Предоставление плана в SOC до получения первого инцидента о работе КК – по решению Заказчика, но приветствуется, так как сократит коммуникации и ускорит атрибуцию.
2. Во время проведения работ
2.1. При получении алертов, SOC регистрирует инцидент в рабочем порядке с рекомендациями по реагированию, публикует его Заказчику, при необходимости информирует в установленном в SLA порядке.
2.2. Заказчик, имеющий план работ КК, принимает решение является выявленная SOC активность действиями КК или нет. Если выявленный инцидент SOC является следствием работы КК, Заказчик передает все АКК и состав исполнителей в SOC, чтобы последующих оповещений по этому инциденту не было, а SOC аккуратно отслеживал эту активность, исключая интерференцию с другими инцидентами, но, вместе с тем, не экономил время на оформлении карточки инцидента.
2.3. Если Заказчик согласует предложенное реагирование, инцидент прекращается. Если инцидент не прекращается, то пп. 2.1-2.3 повторяются. Далее рассматриваем сценарий, когда SOC поставлена задача отслеживать работу КК, без реагирования со стороны SOC.
2.4. Технически, SOC добавляет все АКК в observables используемой IRP, чтобы для все новые алерты автоматически ассоциировались с данным инцидентом о работе КК. Неразмеченные сырые события в окрестности алертов, релевантных КК, не анализируются (это позволит экономить ресурсы SOC). Плановые мероприятия ручного Threat hunting-а проводятся в соответствии с обычными операционными регламентами в рабочем порядке.
2.5. Если о работе КК заводятся дополнительные инциденты, они явно связываются первым оформленным инцидентом о работе КК, аккуратно указываются observables, для обеспечения автоматического связывания алертов механизмами IRP.
2.6. Если SOC не уверен является ли наблюдаемая активность инцидентом, то в любом случае лучше опубликовать инцидент, так как цена пропуска значительно выше себестоимости ложного срабатывания.
3. После окончания работ КК. Заполнение Таблицы используемых техник
3.1. КК готовит табличку (п. 3.3.) с перечислением всех выполненных действий. Степень детализации – с точностью до реализации конкретной техники MITRE ATT&CK (строчка – одна реализация техники, процедура)
3.2. SOC (вторая и\или третья линия) анализирует алерты и ханты по каждой строчке таблицы п.3.1. Где алертов и хантов, а, может, и событий телеметрии, не было – это область роста, здесь вырабатываются мероприятия по развитию, чтобы данная реализация данной техники в будущем размечалась, а при адекватной степени фолсовости, поднималась и до алерта. К разработке мероприятий по развитию, при необходимости, подключаются команды разработки и Detection engineering (третья линия).
3.3. Колонки п. 3.1 заполняются КК, помечены (КК), колонки п. 3.2., помечены (SOC), заполняются командой SOC.
Колонки таблицы:
- метка времени (КК) - дата и время действия
- источник (КК) - IP/имя источника активности. Если используется цепочка proxy, перечисляются все хопы, с необходимыми пояснениями.
- хост (КК) - IP/имя хоста, где производилась активность
- контекст пользователя (КК) - имя учетной записи и ее полномочия, от кого выполнялись действия на хосте
- используемый инструмент (КК) - какой инструмент использовался аудитором, с необходимыми пояснениями
- командная строка (КК) - команды, запускаемые на источнике и\или хосте
- метка времени в SIEM (SOC) - дата и время первого сырого события, релевантного активности, если события (телеметрия) есть
- событие в SIEM (SOC) - ссылка на события телеметрии, или их копия
- метка времени в IRP (SOC) - дата и время соответствующего алерта, есть есть
- сработавшее правило\хант (SOC) - ссылка на описание сработавшего правила обнаружения
- Комментарии (SOC) - любые пометки\пояснения
- TODO (SOC) - план мероприятий по совершенствованию - ссылки на соответствующие требования\CR\BRq\User story
