sims718718/unifiedthreathuntingОписывает структурированную, воспроизводимую методологию охоты за угрозами, охватывающую триггеры, SMART-гипотезы, критерии осуществимости, определение области, планы охоты и отчётность о результатах для команд безопасности.
Как ведущий специалист по охоте за угрозами, я получил задачу построить программу охоты за угрозами с нуля. Это потребовало множества размышлений о том, что такое охота за угрозами на самом деле и как превратить её в значимые результаты. Многие часы ушли на изучение различных методологий охоты за угрозами, инженерии обнаружения, киберразведки (CTI), форензики и даже опыта, полученного за время службы в Военно-воздушных силах США. Однако в процессе построения программы я осознал, что мне нужен единый процесс — Единый процесс охоты за угрозами. Я разработал этот процесс, чтобы обеспечить структурированный и определённый способ охоты и в конечном итоге достичь значимых результатов для организации.
graph LR
Z[Step 0: Environment Context] --> A[Triggering Event]
A --> B[Hypothesis Development]
B --> C[Initial Assessment]
C --> D[Feasibility Assessment]
D --> E[Define Scope & Objectives]
E --> F[Formalize Hunt Plan]
F --> G[Execute Hunt]
G --> H[Document Outcomes]
H --> I[Report & Iterate]
I --> A
Threat hunting — это проактивный поиск угроз, которые обошли ваши средства защиты. Это определение устоялось; а вот как реализовать его как процесс — нет. Этот процесс представляет собой синтез, и таблица — честный отчёт о нём:
| Источник | Что он привносит сюда |
|---|---|
| Sqrrl / Hunting Maturity Model (Bianco) | Основной цикл и лестница зрелости, используемые в Maturity & Metrics |
| TaHiTI | Триггер как истинная отправная точка и передача смежным процессам при закрытии |
| PEAK | Типизация охоты (гипотеза / базовый уровень / с применением моделей) и ориентированное на результат закрытие «действуй со знанием» |
| AIMOD2 | Предпосылка assumed breach и типизированные категории результатов |
| OTHF | Операционная рамка для проведения охот как повторяемой командной функции |
| Этот процесс добавляет | Шаг 0 «Контекст среды» · жёсткий шлюз выполнимости GO / NO-GO / CONDITIONAL · Jira Epic/Story/Task с типизированными результатами · гипотезу с рубрикаторным контролем и специфицированную передачу детектирования |
Отличия — в последней строке. Всё остальное опирается на работу других людей, цитируемую в References.
Существуют различные описанные методы проведения охотничьих операций: структурированные, неструктурированные, ориентированные на TTP, ориентированные на разведданные, управляемые данными и так далее. Хотя этот Unified Threat Hunting Process может показаться структурированным, это не значит, что ваша гипотеза не может быть управляема данными неструктурированным образом. Этот процесс стремится объединить различные типы threat hunting, допуская модульный подход. Мы бы использовали все эти техники, чтобы гарантировать тщательную проверку нашей гипотезы.
Цель — модульный подход к threat hunting, где нет универсального решения. Используйте все доступные вам техники.
На практике выбранный вами тип охоты зависит от того, с чего вы начинаете в цепочке DAIKI (Data → Information → Knowledge → Insight):
| Тип охоты | Отправная точка | Характеристики |
|---|---|---|
| Exploratory (EDA) | Сырые данные | Создание базового уровня, понимание формы данных, отсутствие предварительной гипотезы |
| Hypothesis-Based (HBO) | Ситуационная осведомлённость | Проверка правдоподобных сценариев атак на основе знаний команды |
| Threat-Informed (TIO) | Применимая CTI | Управляемая разведданными, фокус на известном акторе или TTP |
| Purple Operations (DPO) | Инсайт red team | Совместная валидация наступательной и оборонительной сторон |
Следуя принципам data science, независимо от типа охоты, вам следует стремиться исследовать и понимать источники данных, относящиеся к вашей охоте. Папка /Data_Analysis в этом репозитории содержит вспомогательные техники и ноутбуки для этой фазы исследования.
Кроме того, Threat Intelligence, будь то отправная точка или нет, встроена во весь процесс, помогая управлять операциями.Threat Intelligence
Примечание: Хотя обычно вы хотите сосредоточиться на поведении или TTP, IoC имеют свою ценность, если они действительно применимы и своевременны. Хотя охота на IoC по всей среде — это не совсем threat hunting, они всё же могут предоставить полезную информацию и ещё одну отправную точку. Они могут быть частью цикла охоты, но не всей охотой целиком.
Прежде чем начнётся любая охота, зафиксируйте среду, чтобы каждый последующий артефакт (запросы, имена полей, решения по охвату) был адаптирован к тому, где вы действительно работаете, а не написан обобщённо. Я добавил это как явный шаг, потому что постоянно видел планы охот, ссылающиеся на источники данных, которых ни у кого не было, или запросы, написанные совершенно на другом диалекте. Несколько минут здесь экономят часы позже.
Как минимум задокументируйте:
| Контекст | Почему это важно |
|---|---|
| SIEM / платформа данных | Splunk SPL, KQL, Elastic DSL и Chronicle каждый по-своему формируют каждый написанный вами запрос |
| Платформа EDR | CrowdStrike, SentinelOne, Defender for Endpoint используют разные имена полей телеметрии |
| Тип среды | On-prem, cloud-native (AWS/Azure/GCP) или гибридная среда меняет то, какие логи вообще существуют |
| Отраслевая вертикаль | Определяет, какие threat actors реалистично релевантны |
| Окна хранения логов | Определяют, какие временные диапазоны действительно возможно запрашивать |
| Уровень зрелости охоты | Новичкам в охоте нужны строительные леса; опытные команды хотят скелет |
Задокументируйте это как блок Environment Profile в начале Epic. Если вы работаете быстро, абсолютный минимум — платформа SIEM и тип среды; всё меньшее — и ваши запросы будут обобщёнными.
Охота в нескольких организациях? (MSSP/MDR, федеративные дочерние компании или общая платформа SIEM.) Держите один профиль на тенанта в реестре
tenants/<id>/profile.yaml, и пусть каждый Epic ссылается наtenant: <id>вместо встраивания профиля. Перед оценкой выполнимости проверьте авторизацию: тенант без покрытия RoE/контрактом или запланированное действие вне егоallowed_actions— это NOT AUTHORIZED, и на этом всё останавливается. Команды с одной организацией могут это пропустить. См. Multi-Tenant Operation.
Заимствуя из фреймворка TaHiTI, threat hunting начинается с триггерного события. Эти события оправдывают инициирование охоты. Согласно TaHiTI, триггеры могут включать:
В нашей организации мы используем их вместе с несколькими дополнительными триггерами, такими как прямые требования от стейкхолдеров и раскрытия уязвимостей, затрагивающих среду.
Некоторые фреймворки начинают threat hunt с исходной Гипотезы (шаг 2 здесь), но я спрашиваю: как вы вообще приходите к этой гипотезе?
Вероятно, есть триггерное событие, которое ведёт к исходной гипотезе. Точно так же, как Исаак Ньютон наблюдал падение яблока, прежде чем задуматься, какая сила притянула его вниз, это яблоко было триггерным событием, которое привело к гипотезе о гравитации. Аналогично, у нас должен быть триггер, прежде чем мы вообще дойдём до гипотезы.
