Силачом слыву недаром - семерых одним ударом
Братья Гримм "Храбрый портняжка"
Уже достаточно давно, в замечательной статье Психология безопасности Брюс Шнайер, писал о том, что надо отличать фактическую безопасность от ощущения безопасности. Поскольку фактическую безопасность непросто обеспечить и не менее сложно объективно подтвердить, есть нехорошая тенденция, когда пропагандируются простые зависимости, вроде, если будешь делать А, то будешь в безопасности. К сожалению, не все так просто на практике, а, поскольку подобные зависимости создают ложное ощущение безопасности (тем более, что надо постоянно искать), будем потихоньку их обсуждать, по мере наших скромных возможностей. Мы уже обсуждали модные в последнее время киберполигоны, а сегодня поговорим о BAS (первая ссылка, которую мне выдал Google на русском языке).
Неправильное позиционирование BAS следует прямо из постулируемого назначения: проверка СЗИ, детектирование техник, развитие SOC... - приписывание BAS решение этих задач практически равносильно утверждению: "Все что блестит - золото".
Детектирование техник. Те, кто читал ATT&CK, прекрасно понимает, что не надо делать алерт на каждую технику, а кому это не очевидно, MITRE в своей доке явно это написали: "At its core, ATT&CK documents known adversary behavior and is not intended to provide a checklist of things that need to all be addressed. Not all adversary behaviors can or should be used as a basis for alerting or providing data to an analyst." А раз так, то техник надо детектить не больше, чтобы не быть заваленным ложными срабатываниями, и не меньше, чтобы не пропустить атаку. А где та самая золотая середина - это вопрос серьезного исследования: почему именно эти техники выбраны? они действительно попадают в компромисс по количеству ложных срабатываний? а, кстати, какая конверсия по данному конкретному правилу считается допустимой? на каком основании сделан этот вывод о допустимости такой конверсии? Причем, использование этой конкретной техники в реальных атаках - не основание, как минимум, потому использование техник в дикой природе - основной критерий попадания в ATT&CK (там нет "искусственных" техник, только те, что уже использовались ITW). Но ситуация даже еще хуже: мы детектим не технику, а процедуру, и тут намного больше степеней свободы: на чем основано решение, что нужно сделать детект именно под эту процедуру (это тоже вопрос исследований и TI)?
В общем, любой BAS покрывает какое-то подмножество техник и их конкретных реализаций (процедур) и насколько это подмножество отражает реальную картину, релевантную нашей инфраструктуре, и насколько это подмножество разумно детектить ввиду ложных срабатываний - вопрос глубоких исследований. Не следует ожидать алерт на каждый запуск PoserShell, или вывод имени хоста, или запуск ps, достаточно и событий телеметрии, а уже аналитик при построении таймлайна, зацепившись на менее склонный к ложным срабатываниям алерт, обратит внимание на эти события.
Проверка СЗИ. Тут, конечно, многое зависит от того, что вкладывается в понятие "проверка". Как обсуждали выше, делать алерт на каждую проверку не имеет смысла и даже вредно, достаточно и событий телеметрии, а в ряде случаев, можно обойтись и без событий. Вообще, если на каждую проверку BAS ожидается алерт, а с т.з. SOC алерт - это следствие вредоносной активности, то что мешает все источники алертов (источники вредоносной активности) просто повыносить с помощью EPP? Если мы эмулируем вредоносную активность, давайте эмулировать и респонс на нее! И даже если СЗИ покрывает алертами все, что BAS проверяет, это совсем не означает, что СЗИ эффективно отреагирует в случае реальной атаки: и процедуры могут быть не те, что BAS выбрал для проверки, и нет гарантии, что детектится не эмуляция действия, а сам BAS.
Развитие SOC. Процессные кибеучения и TTX - дело полезное. Здесь полная аналогия с тренировкой эвакуации при пожаре: чтобы избежать хаотичности, избежать "забега в ширину", а получить управляемое, повторяемое взаимодействие, надо тренироваться. Управление инцидентами - не исключение. Если мы посмотрим цикл управления инцидентами, то несложно догадаться, что мероприятия по обнаружению требуют значительно меньше взаимодействия разных исполнителей, чем в рамках работ по локализации, расследованию и реагированию на инциденты. В большинстве случаев, обнаружение, триаж и инструментальное реагирование (средствами EDR/EPP) выполняет один аналитик SOC, а в случае BAS, аналитик сразу заметит, что имеет дело с BAS, поэтому отрабатывать какое-либо взаимодействие с кем-либо возможность не предствится.
Кто-то на основании BAS проводит сравнение СЗИ с целью выбора. С учетом сказанного выше, успешность этого мероприятия сомнительна. Ну, разве что, можно будет с уверенностью сказать какое СЗИ лучше детектит данный конкретный BAS, что едва ли релевантно качеству его работы применительно к реальным атакам.
Очень просто критиковать, но очень сложно предлагать альтернативу, - прекрасно это понимаю, поэтому предлагаю сценарии использования BAS, в которых он будет действительно полезен.
Проверка своей детектирующей логики. Создание правила - это только начало, далее им надо управлять, т.е. постоянно контролировать его эффективность и результативность - нам надо постоянно гарантировать, что правило срабатывает в сценариях, где должно срабатывать и не фолсит там, где не должно выдавать ложные срабатывания. Правила нестатитчны, в них постоянно добавляются клиенсткие фильтры, а, возможно, и корректируются\добавляются новые сценарии. Каждое изменение может частично (в некоторых сценариях) или полностью (во всех сценариях) сломать правило, поэтому его надо постоянно контролировать. Ну, конечно, это надо делать не вручную, поскольку правила и сценарии измеряются тысячами - это отличное поле для BAS: проверка срабатывания конкретных правил при эмуляции конкретных сценариев атак и, при необходимости, не срабатывания при эмуляции конкретных сценариев ложных срабатываний.
Проверка успешности против конкретной атаки. Мы учимся на опыте, не раз говорили, что исследование прошлых атак - идеальная база для развития технологий обнаружения. Тестирование MITRE и предлагаемый ранее сценарий отечественного аналога "Открытое тестирование" - вполне объективный подход к сравнению решений, предоставляющий заказчику подтверждаемый результат качества продукта. Вопросы автоматизации как раз мог бы решить BAS. Какие техники и процедуры выбрать здесь определяется конкретной известной атакой\кампанией, а за что там имеет смысл "зацепиться", соблюдая компромисс между пропуском и океаном ложных срабатываний - решают участники тестирования.
Как любая технология, BAS имеет ограничения, поэтому воспользоваться их эффективностью и результативностью можно лишь в определенных сценариях. Использование же BAS в сценариях, где он неэффективен, тем более, составление каких-либо прогнозов и принятие каких-либо управленческих решений на основе полученных результатов его работы, не имеет смысла, а иногда бывает просто опасно.
