Мы привыкли к стандартным планам реагирования, которые представляют собой либо развесистые алгоритмы действий, покрывающие большое количество ситуаций, либо много маленьких плейбуков, специализированных под конкретный тип инцидента. При этом инфраструктура предприятия – живой организм, который постоянно меняется: добавляются новый устройства, сегменты сети, меняются политики работы ноутбука важного босса, добавляются СЗИ. По этой причине в организациях с развитым уровнем ИБ регулярно проводятся аудит и инвентаризация, которые помогают актуализировать информационную модель предприятия, но меняются ли по результатам инвенторки плейбуки?
Следующий аспект, влияющий на эффективность защиты – переменчивость внешнего окружения. В текущих реалиях техники реализации атак эволюционируют, усложняются, затрагивают новые типы данных инфраструктуры, используют новые механизмы и способы посткомпрометации (например, программы-вымогатели ransomeware теперь не только шифруют данные организации и требуют оплату за восстановление доступа, но могут также воровать информацию организации, требуя дополнительную плату в обмен на неразглашение информации властям, конкурентам или общественности).
В силу постоянно меняющегося ландшафта угроз и способов их реализации наши плейбуки тоже должны изменяться, чтобы не устаревать на фоне меняющегося поведения злоумышленников.
Для решения первой задачи (изменчивости инфраструктуры) был разработан подход, который в зарубежном сообществе трактуется как CD/CR, или непрерывность обнаружения и реагирования.
Он заключается в применении лучших практик ООП к выстраиванию процессов информационной безопасности. Первыми об этой технологии как о перспективной разработке заявила корпорация Google. В разрезе их исследований предлагается разбить процессы и процедуры ИБ до атомарных функций, которые можно переиспользовать и которые являются по сути небольшими унифицированными процессами по выполнению операции. Атомарные унифицированные процессы хранятся в репозитории; функция выполняется единственным экземпляром рабочего процесса, который правится в одном месте разными заинтересантами (таким образом мы соблюдаем консистентность) и, когда возникает необходимость, этот процесс стандартным образом включается в плейбук за счет унифицированного input/ouput.
Примером унифицированного процесса может быть процедура сбора аутентификационных сессий с хоста. Она может быть выполнена разными способами и разными средствами в зависимости от типа хоста, политик использования хоста или закрывающего СЗИ. Но если все эти вариации обрабатываются в рамках одного универсального процесса сбора аутентификаций с одним стандартным input/ouput, то строить процессы ИБ становиться уже гораздо проще. Атомарный процесс, ко всему прочему, будет переиспользован в совершенно разных процессах ИБ: не только при построении динамических плейбуков в инцидент менеджменте, но еще и в ассет менеджменте, IDM и т.д. Набор таких универсальных процессов дает нам возможность формировать кастомный подход к кастомной инфраструктуре.
Но мы рассмотрели способ решения лишь первой части проблемы – актуальности инфраструктуры. Также нам нужно решить проблему обфускации проведения атак, что по сути своей является уже дедуктивным расследованием, которое сложно покрыть корреляционным движком. В какой-то степени отклонения от поведения можно покрыть через анализ аномалий (UEBA) и все равно это не то, что нам нужно: поиск аномалий в поведении устройств/человека и отклонения в исполнении атак – это разные вещи. Зато, если подумать, какая специализация или область знаний занимается поиском признаков компрометаций устройств или уровня защищенности, то первое, что приходит на ум – технология thereat hunting (построение гипотез по поиску подозрительной активности). И действительно, контролирование изменчивости проведения техник атак через распространенные признаки компрометации устройств – одна из задач, решаемых аналитиками 3-ей линии, специализирующихся на поиске угроз.
Если использовать подходы threat hunting в применении к окрестностям инцидента, то мы можем найти дополнительные обьекты, которые были скомпрометированы, несмотря на то, что ранее техника проведения атаки их не поражала. Например, эксплуатация уязвимости не компрометировала уровень защищенности или вирус не подгружал какой-то хакерский tool set.
Подозрительная активность может быть совершенно разноплановой, поэтому ручной поиск угроз – настолько трудоемкая процедура, требующая навыков и знаний в совершенно разных предметных областях. В реализации одной угрозы используются слабости протокола, что требует знание сетевых технологий; другая угроза реализуется через кастомное шифрование – знание крипты. Разобраться в том, как работает rootkit, нам помогут знания программирования: индикаторы подозрительной активности могут быть столь разными, что бэкграунд у специалиста должен быть большой, как у врача-терапевта. Хорошая новость заключается в том, что часть этих задач можно автоматизировать, если использовать современные наработки поиска угроз с помощью sigma, microsoft threat detection, elastic security rules, аналитиз алертов IDS систем.
Вот что можно найти в окрестностях инцидента, если автоматизировать threat hunting:
Внутреннее сетевое сканирование и попытки эксплуатации уязвимостей внутри сети
Подозрительную сетевую активность системных утилит rundll32, regsvr32, mshta, certutil
Запуск командных интерпретаторов (powershell, cmd, wscript, cscript) офисными приложениями (word, excel)
Запись в ключи реестра, отвечающих за автозагрузку либо за изменение системных настроек ОС
Создание служб, задач планировщика с powershell, а также LOLbins утилитами
Запуск пользователем нерегламентированного ПО (утилиты администрирования, VPN клиенты, TOR, torrent клиенты и т.д.).
Подозрительные процессы находятся по подозрительным родителям системных процессов:
В командной строке можно найти код powershell с пэйлоадом в base64, что означает обфускацию кода, а там уже может быть что угодно: архив в архиве, зашифрованные команды и т.д. Админы, естественно, скрывать свою деятельность не будут, и это явный признак подозрительной активности:
Запуск admin tools из-под непривилегированного пользователя, подозрительное повышения привилегий до системной учетки и прочее, прочее... Этот подход может дать нам огромный набор дополнительной информации и новые пораженные объекты инцидента.
Если мы встраиваем поиск этих объектов в анализ инцидента, динамический плейбук будет базироваться на реальном актуальном контексте атаки, то есть на всех объектах из состава инцидента.
Итого, мы получим настоящую область поражения, по которой из репозитория процессов можно начать собирать объектно-ориентированное реагирование:
выбираем множество возможных атомарных процессов реагирования для внутренних хостов
выбираем набор процессов реагирования для скомпрометированного уровня защищенности
или для ВПО, почты и многого другого.
Из них начинает выстраивается динамический плейбук: если этот тип объекта появился, процесс добавляется в процесс реагирования. Множество универсальных процессов реагирования на множестве объектов ограничивается рекомендациями по выполнению конкретных действий, в зависимости от техники атаки, определенной в процессе классификации инцидента. То есть динамика плейбука заключается в изменении состава действий, в зависимости от пораженных объектов и техники атаки. Этот подход позволяет создавать пайплайн действий, актуальный конкретной ситуации.
Еще один важный момент – это выстраивание цепочки атаки из отдельных инцидентов в связанную историю, отображающую ландшафт атаки, растянутой по периметру, времени и способам исполнения. В действительности атаки становятся все более комплексными и сложными, из инцидентов с различными техниками, которые еще и связаны между собой довольно неочевидными вещами (например, наличием в инцидентах одного и того же процесса, либо использование однотипного named pipes). Конечно же, подобные ситуации не покрыть стандартными планами реагирования, но если добавить в стандартные подходы динамическую составляющую, то мы можем связать инциденты по идентичным объектам и контексту: запуски аналогичных подозрительных процессов, сетевых аутентификаций, задействованных уровней защищенности. Одни и те же задействованные хосты в разных инцидентах, скорее всего, говорят о своей принадлежности к одному и тому же kill chain. При таком подходе наши инциденты становятся связанными, а динамические плейбуки выстраиваются в последовательность работы над атакой, то есть переходят на более высокий стратегический уровень планов реагирования.
Если проанализировать собранную информацию через классификацию по угрозам Mitre Att@ck или БДУ ФСТЭК, то этапы kill chain вообще преобразуются в последовательность тактик, применяемых нарушителем, на которые с нашей стороны динамически выстраивается контекстный ответ.
При текущей волатильности в ИБ, очень быстро меняющихся как поведения нарушителя, так и состояния защищаемых инфраструктур, нужно применять соответствующие симметричные динамичные подходы.
