Atomic Red Team: проверка своих средств обнаружения по MITRE ATT&CK
Правило в auditd или Wazuh может годами лежать невостребованным, если его никто не проверял тестовым срабатыванием. Atomic Red Team — открытая база коротких, документированных тестов, каждый привязан к конкретной технике из каталога MITRE ATT&CK: не инструмент атаки, а каталог «вот так выглядит эта техника на практике», которым можно проверить собственные детекторы на своей же системе. Это purple team: вы одновременно и имитируете поведение, и смотрите, заметила ли его защита.
Статья опирается на логику направления «Мониторинг кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Проверка выполнена на тестовой системе с публичным описанием теста T1003.008 из репозитория Atomic Red Team, после неё всё удалено.
Что должно получиться
| Уровень | Что это значит на практике |
|---|---|
| 2. Гигиенический | Правила обнаружения проверяются тестовым срабатыванием, а не только пишутся и забываются; известно, какие техники ATT&CK реально покрыты |
Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.
Как устроен один тест
Каждый тест в репозитории — короткое описание конкретного шага одной техники, с готовой командой и шагом очистки после. Например, T1003.008 («OS Credential Dumping: /etc/shadow») описывает ровно то, что реально делает злоумышленник на этом шаге — читает файл с хэшами паролей:
sudo cat /etc/shadow > /tmp/T1003.008.txt
# шаг очистки:
rm -f /tmp/T1003.008.txtЭто не эксплойт и не инструмент для взлома — сам факт чтения файла, доступного команде cat из командной строки любому с нужными правами. Ценность не в команде (она тривиальна), а в привязке к конкретной технике каталога и в том, что это стандартный, документированный шаг, которым пользуются многие команды для сравнимых результатов.
Порядок проверки
- Выберите технику, которую должно покрывать существующее правило (например, доступ к файлу с хэшами паролей — у вас должно быть правило на чтение
/etc/shadow). - Найдите соответствующий тест в репозитории
atomics/по идентификатору техники. - Выполните команду теста на тестовой или собственной системе, где работает правило.
- Проверьте, сработало ли правило, в журнале обнаружения.
- Выполните шаг очистки теста.
Результат проверки
На тестовой системе с правилом auditd -w /etc/shadow -p r -k credential_access выполнение команды теста T1003.008 дало в журнале запись с полями comm="cat", name="/etc/shadow", key="credential_access" — правило сработало именно на то действие, которое описывает техника. Это подтверждает: правило реально ловит технику, а не просто существует в конфигурации.
ausearch -k credential_access -ts recentЕсли бы в журнале не было соответствующей записи, это значило бы одно из двух: правило не загружено (проверка auditctl -l) или оно написано не так, как реально ведёт себя система (например, ждёт другой путь к файлу или другой тип доступа).
Порядок внедрения
- Составьте список техник, которые, по вашей оценке, покрыты существующими правилами мониторинга (политика журналирования — хороший источник для этого списка).
- Для каждой техники найдите подходящий тест в репозитории и запустите на тестовой системе, не на проде напрямую при первом прогоне.
- Зафиксируйте результат: сработало правило или нет, с датой проверки — это ваша карта реального покрытия, не предполагаемого.
- Для техник без правила — решите, заводить правило или осознанно принять технику как непокрытую (часто оправдано для низкой вероятности в вашем контексте).
- Повторяйте раз в квартал или при значимом изменении инфраструктуры мониторинга — правило, работавшее вчера, может перестать срабатывать после обновления агента или изменения конфигурации.
Диагностика
| Симптом | Причина и что делать |
|---|---|
| Тест выполнен, журнал пуст | Правило не загружено или написано для другого условия. Сверьте auditctl -l и точный путь/тип доступа в правиле |
| Непонятно, какой тест соответствует какому правилу | Идентификатор техники в описании правила и в каталоге репозитория — общий язык. Привязывайте правило к конкретному ID техники при создании |
| Команда теста требует Windows-окружения или PowerShell-модуля | Часть тестов написана для Windows и использует отдельный раннер (Invoke-AtomicRedTeam). Для Linux ищите тесты с supported_platforms: linux и выполняйте вручную, как показано выше |
| Прогнали тест на проде и что-то сломалось | Даже безопасные тесты (создание файлов, чтение) стоит сначала проверять на тестовой системе. Для прода — только после проверки на тесте |
Ограничения
Один сработавший тест подтверждает одно правило на одном шаге одной техники — это не полноценный пентест и не гарантия, что та же техника, выполненная другим способом, тоже будет замечена. Для полной картины нужен не один прогон, а систематическая сверка покрытия (матрица техник против правил), и регулярное обновление по мере изменения каталога ATT&CK и собственной инфраструктуры.
Где это в модели зрелости
Материал относится к направлению «Мониторинг кибербезопасности» (материалы направления, карта зрелости). Уровень 2 требует, чтобы обнаружение было подтверждено на практике, а не только задокументировано: контролируемая проверка связывает правила мониторинга с конкретными техниками и даёт объективный ответ, работает защита или нет.
Как проверить
- Есть список техник ATT&CK, которые предполагаются покрытыми, с привязкой к конкретным правилам мониторинга.
- Для каждой техники хотя бы раз выполнена проверка тестовым срабатыванием и зафиксирован результат с датой.
- Непокрытые техники — осознанное решение, а не забытый пробел.
- Проверка повторяется по расписанию, а не проводится один раз и забывается.
Источники
- Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.
- Репозиторий Atomic Red Team: github.com/redcanaryco/atomic-red-team; каталог техник MITRE ATT&CK: attack.mitre.org.
