По данным CrowdStrike Global Threat Report 2025, среднее время горизонтального перемещения атакующего после первичного доступа - 62 минуты. Рекорд - 51 секунда. На gap-анализе прошлого года я смотрел инфраструктуру компании с действующим сертификатом ISO 27001 и увидел знакомую картину: контроль A.8.16 (Monitoring activities) формально существовал, SIEM жевал Windows Security-логи, но ни одного правила корреляции под техники lateral movement - T1021 Remote Services, T1550 Use Alternate Authentication Material - не было. Три дня атакующий гулял по сети. Ноль алертов. Сертификат висел на стене, аудитор ставил галочку напротив A.8.16 за полгода до инцидента.
Почему контроли ISO 27001 Annex A не останавливают lateral movement
ISO 27001:2022 описывает 93 контроля в Annex A. Каждый формулирует требование на уровне "что должно быть сделано?" - защита аутентификации, журналирование, мониторинг активности. Ни один контроль не объясняет, какое конкретно поведение атакующего нужно обнаруживать. Стандарт работает на уровне governance: распределение ответственности, управление рисками кибербезопасности, процессное управление ISMS. Это его архитектурная задача - и он её решает.
MITRE ATT&CK решает обратную задачу: систематизирует конкретные тактики, техники и процедуры (TTPs) реальных атакующих. Матрица MITRE ATT&CK не скажет, кто отвечает за патч-менеджмент, - зато покажет, что Valid Accounts (T1078, Initial Access, Persistence, Privilege Escalation, Defense Evasion) используется для закрепления через скомпрометированные легитимные учётные записи.
Противопоставлять эти фреймворки - методологическая ошибка (и на Хабре об этом справедливо писали). Они работают на разных уровнях архитектуры безопасности. Проблема в другом: без операционного маппинга между ними контроли Annex A покрыты на бумаге, а между ними зияют пустоты, через которые проходит атакующий.
Скомпрометированные учётные записи: провал формальных контролей
IBM X-Force Threat Intelligence Index 2025 фиксирует рост атак с использованием действительных учётных данных на 71% год к году. По данным Verizon DBIR 2025, 38% утечек связаны с кражей credentials. Контроль A.8.5 (Secure authentication) из ISO 27001:2022 требует механизмов безопасной аутентификации: MFA, парольные политики, управление сессиями. Формально это покрывает T1078 Valid Accounts. На практике - нет.T1078 охватывает сценарии, которые A.8.5 не адресует напрямую:
- Использование украденных токенов OAuth без пароля
- Авторизация через данные, собранные infostealers (по IBM, infostealers - 32% всего malware в 2024)
- Компрометация service accounts с бессрочными паролями
- Insider threat: легитимный сотрудник, действующий за рамками baseline поведения
- Скомпрометированные хосты, выглядящие чистыми для endpoint protection
Финансовый контекст делает этот разрыв болезненным. Российское законодательство ввело оборотные штрафы за утечку персональных данных. Сертификат ISO 27001 не спасёт, если инцидент произошёл из-за отсутствия операционного обнаружения TTPs. Формальный аудиторский чеклист и защита инфраструктуры через threat-informed defense - разные вещи.
ATT&CK mapping контролей безопасности ISO 27001: таблица покрытия
Ниже - маппинг ключевых технологических контролей ISO 27001:2022 на техники MITRE ATT&CK с указанием операционных пробелов. Таблица построена на основе gap-анализов для трёх организаций с действующей ISMS.
| Контроль ISO 27001:2022 | ATT&CK-техника | Тактика | Что контроль НЕ закрывает |
|---|---|---|---|
| A.8.5 Secure authentication | T1078 Valid Accounts | Initial Access, Persistence | Behavioral detection: аномальное время входа, геолокация, credential reuse |
| A.8.7 Protection against malware | T1027 Obfuscated Files or Information | Defense Evasion | Fileless-атаки, обфускация base64 в PowerShell, living-off-the-land |
| A.8.8 Management of technical vulnerabilities | T1190 Exploit Public-Facing Application | Initial Access | Разрыв между cadence патчинга и скоростью эксплуатации |
| A.8.15 Logging | T1059 Command and Scripting Interpreter | Execution | Логи собираются, но без правил корреляции под PowerShell, cmd, bash |
| A.8.16 Monitoring activities | T1021 Remote Services | Lateral Movement | Мониторинг без baseline нормального поведения RDP/SMB/WinRM |
| A.8.20 Networks security | T1071 Application Layer Protocol | Command and Control | Сегментация не детектирует C2 через HTTPS/DNS tunneling |
| A.5.7 Threat intelligence | T1566 Phishing | Initial Access | Threat intel не маппится на покрытие конкретных sub-techniques |
По данным Mandiant M-Trends 2025, exploits - 38% всех векторов initial access. Контроль A.8.8 задаёт процесс управления уязвимостями, но не определяет SLA на патч критических CVE. А IBM X-Force фиксирует среднее время между публикацией CVE и устранением в организации - 29 месяцев. Маппинг показывает разрыв: стандарт информационной безопасности говорит "управляйте уязвимостями", а ATT&CK показывает, что T1190 эксплуатируется за дни.
Цепочка атаки через призму маппинга
Разберём типовую kill chain и посмотрим, где каждый контроль ISO 27001 встаёт - и где обрывается.Initial Access - T1566 Phishing (Initial Access): письмо с ISO-вложением. Контроль A.8.7 детектирует известные сигнатуры. Sigma-правило
win_security_iso_mount.yml (одно из 36 правил, тегированных T1566 в SigmaHQ, включая deprecated и кросс-платформенные) ловит монтирование ISO-файлов, но его нужно импортировать в SIEM. A.8.7 этого не требует. По Verizon DBIR 2025, фишинг остаётся вектором initial access в 36% инцидентов.Execution - T1059 Command and Scripting Interpreter (Execution): запуск PowerShell. Контроль A.8.15 фиксирует событие только при включённом расширенном журналировании (Module Logging, Script Block Logging). Без них - слепая зона. В SigmaHQ для T1059 доступно 397 правил, включая
proc_creation_win_powershell_dsinternals_cmdlets.yml.Credential Access - T1110 Brute Force или T1552 Unsecured Credentials: извлечение учётных данных из конфигурационных файлов, скриптов, переменных окружения. Контроль A.8.5 ограничивает попытки входа, но не детектирует само извлечение credentials.
Lateral Movement - T1021 Remote Services (Lateral Movement): перемещение через RDP/SMB. Контроль A.8.16 требует мониторинга, но без baseline - что считать нормальным RDP-сеансом - любое детектирование тонет в шуме.
Command and Control - T1071 Application Layer Protocol: C2 через HTTPS. Контроль A.8.20 описывает сегментацию сетей, но не требует анализа зашифрованного трафика или JA3/JA4-fingerprinting.
Каждый контроль Annex A покрывает один срез. ATT&CK mapping контролей безопасности выявляет пустоты между этими срезами.
Gap-анализ покрытия через ATT&CK Navigator
ATT&CK Navigator - бесплатный инструмент MITRE для визуализации покрытия техник атак. Вот процесс gap-анализа, который я использую на реальных аудитах:
Шаг 1. Создать слой (layer) с техниками, формально покрытыми контролями ISO 27001 Annex A. Пометить зелёным. Для маппинга использовать таблицу выше - или расширенный вариант из проекта MITRE CTID (Center for Threat-Informed Defense), где опубликован маппинг NIST SP 800-53 -> ATT&CK (center-for-threat-informed-defense/attack-control-framework-mappings). Для ISO 27001 потребуется промежуточная таблица соответствия ISO 27001:2022 <-> NIST 800-53, что даёт транзитивный маппинг ISO -> 800-53 -> ATT&CK.
Шаг 2. Создать второй слой с техниками, для которых в SIEM существуют работающие правила корреляции. Пометить синим.
Шаг 3. Наложить слои. Зелёные клетки без синего - контроль ISO 27001 существует, detection отсутствует. Это приоритетные задачи для SOC.
При первом наложении типичная организация с ISO 27001 показывает покрытие правилами корреляции 15-25% от заявленного покрытия контролями Annex A (по моему опыту gap-анализов). Остальные 75-85% - governance на бумаге без операционного обнаружения атак.
Пентест как валидация маппинга
ISO 27001 пентест - обычная часть аудиторского цикла. Проблема: результаты пентеста редко маппятся на конкретные ATT&CK-техники. Пентестер нашёл SQL-инъекцию - отчёт содержит CVSS и рекомендацию, но не привязку к Exploit Public-Facing Application (T1190, Initial Access) и не проверку, сработало ли правило корреляции в SIEM.Threat-informed defense начинается, когда результаты пентеста используются для валидации маппинга:
- Пентестер эксплуатирует T1190 - SOC должен зафиксировать алерт
- Пентестер выполняет T1059 (Command and Scripting Interpreter) - SIEM должен поднять событие
- Пентестер перемещается через T1021 Remote Services (RDP/SMB) - baseline lateral movement должен сработать
D3FEND (knowledge graph защитных техник от MITRE) помогает определить конкретные контрмеры:
- T1078: D3-LAM (Local Account Monitoring) и D3-DAM (Domain Account Monitoring)
- T1190: D3-PMAD (Protocol Metadata Anomaly Detection) и D3-CSPP (Client-server Payload Profiling)
- T1059: D3-DA (Dynamic Analysis) и D3-EFA (Emulated File Analysis)
Detection-чеклист: Sigma-правила и SIEM-корреляция для закрытия пробелов
Чеклист пригоден для включения в отчёт по корректирующим действиям или передачи сисадмину как задание на настройку.
Большинство организаций, с которыми я работал, воспринимают маппинг ISO 27001 на MITRE ATT&CK как разовый проект: сделали таблицу, показали аудитору, забыли до следующего цикла. Это самообман того же порядка, что и "у нас есть SIEM, значит мы защищены". Матрица ATT&CK обновляется - v17.1 вышла в апреле 2025. Угрозы сдвигаются: по Mandiant M-Trends 2025, медианное время обнаружения атакующего в сети сократилось до 11 дней (исторический минимум), но 57% организаций узнают об инциденте от внешней стороны, а не от собственного SOC. Маппинг, сделанный в январе, к июлю устаревает: появляются новые sub-techniques, меняется профиль threat actors для отрасли, Sigma-правила обрастают обновлениями.
Корневая проблема: в большинстве ISMS маппинг ATT&CK не входит в цикл PDCA стандарта ISO 27001. Его делают один раз для аудита и кладут на полку. Threat-informed defense начинается там, где маппинг становится живым процессом: каждый квартал - пересмотр покрытия через Navigator, прогон Atomic Red Team тестов, фиксация результатов как доказательств для A.8.16 и A.5.7. Если SOC не может показать, что правило корреляции сработало на конкретный тест конкретной техники - контроль существует только на бумаге. Организации, которые встраивают этот цикл в ISMS, за два-три квартала поднимают реальное покрытие с 15-25% до 50-60% (по моему опыту на ограниченной выборке). Это уже не галочка для аудитора - это защита инфраструктуры. На codeby.net коллеги ведут тред с практическими playbook'ами по маппингу ATT&CK на compliance-фреймворки - если строите такой процесс, стоит сверить подходы.
Последнее редактирование модератором:
