ISO/IEC 27001 и MITRE ATT&CK решают разные задачи, поэтому прямое сопоставление двух таблиц почти не приносит пользы. Рабочая схема строится вокруг цепочки из бизнес-риска, сценария атаки, техник нарушителя, защитных мер, телеметрии, аналитики, реагирования и контрольного теста. Только такая цепочка показывает, снижает ли компания риск или просто поддерживает комплект документов.
ISO/IEC 27001 задает систему управления безопасностью, ответственность, оценку рисков и требования к проверке результативности. ATT&CK описывает наблюдавшееся поведение злоумышленников и помогает понять, что предотвращать, какие события собирать и как испытывать защиту. Я рассматриваю ISO как управленческий каркас, а ATT&CK как техническую модель угроз внутри каркаса.
Материал предназначен для легальной защиты собственных систем или инфраструктуры, которую разрешено тестировать. Соблюдайте законы своей страны, включая требования российского законодательства. Не применяйте сценарии эмуляции для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений.
Что именно соединяют два фреймворка
Cейчас действует ISO/IEC 27001:2022 с поправкой 2024 года. Стандарт описывает требования к системе управления информационной безопасностью, или ISMS. Организация определяет область действия системы, заинтересованные стороны, активы, риски, владельцев рисков, планы обработки, показатели, внутренний аудит и порядок постоянного улучшения.
Приложение A содержит 93 контрольные меры, разделенные на организационные, кадровые, физические и технологические группы. Однако Annex A нельзя воспринимать как обязательный чеклист из 93 пунктов. Компания сначала определяет нужные меры через оценку и обработку рисков, затем сравнивает выбранный набор с Annex A, чтобы не пропустить существенные меры. Результат фиксируют в Statement of Applicability, где указывают применимые контроли, статус внедрения и обоснование исключений. Подробные рекомендации по реализации контролей дает отдельный стандарт ISO/IEC 27002.
Текущая версия MITRE ATT&CK v19.1 представляет базу тактик, техник, подтехник, программ, групп и кампаний, собранную по открытым данным о реальных операциях. Тактика описывает цель нарушителя, техника показывает способ достижения цели, а процедура отражает конкретную реализацию техники.
ATT&CK не задает допустимый уровень риска, не назначает владельца сервиса и не определяет обязательные для компании меры. База также не служит сертификационным стандартом. Зато ATT&CK добавляет техническую конкретику, которой обычно не хватает реестру рисков и Statement of Applicability.
| Вопрос | ISO/IEC 27001 | MITRE ATT&CK |
|---|---|---|
| Что защищает организация | Область ISMS, активы, процессы и информация | Платформы и объекты, на которых действует нарушитель |
| Почему нужна защита | Бизнес-риск, обязательства и ожидаемый ущерб | Тактическая цель нарушителя |
| Как выглядит атака | Общий сценарий угрозы и риска | Техники, подтехники и процедуры |
| Какие меры выбрать | Необходимые контроли и план обработки риска | Mitigations и сведения о наблюдаемом поведении |
| Что собирать | Требует журналирования и мониторинга | Уточняет компоненты данных и аналитические признаки |
| Как доказать результат | Показатели, аудит, анализ руководством и улучшения | Эмуляция техник, purple team и проверка аналитики |
У ATT&CK есть важное ограничение, которое часто теряется в презентациях. База не содержит все возможные способы атаки, а сведения о группах отражают только публично описанную часть их деятельности. Закрашенная матрица не доказывает, что защита остановит неизвестную процедуру или новую вариацию знакомой техники.
Структура базы также меняется. В ATT&CK v18 прежние Data Sources объявили устаревшими и начали заменять связкой Detection Strategies, Analytics и Data Components. В версии 19 тактику Defense Evasion разделили на Stealth и Defense Impairment. Старую технику T1562 Impair Defenses отозвали, а связанные действия распределили между новыми объектами. Например, отключение защитных инструментов теперь относится к T1685 Disable or Modify Tools, изменение межсетевого экрана к T1686, а загрузка Windows в безопасном режиме для обхода EDR к T1688. Реестр без номера версии ATT&CK быстро начинает ссылаться на устаревшие идентификаторы.
Методика от риска до проверяемого контроля
Я не начинаю с полной матрицы Enterprise ATT&CK и не пытаюсь сопоставить каждую технику со всеми контролями ISO. Такой проект создает сотни спорных связей, которые никто не успевает проверять и обновлять. Сначала выбираю критичный сервис и формулирую сценарий ущерба понятным бизнесу языком.
- Определите границы сценария. Укажите сервис, данные, пользователей, доверенные связи, облачные ресурсы, средства администрирования и резервные копии.
- Опишите нежелательное событие. Например, компрометация привилегированной учетной записи позволяет нарушителю отключить защиту, уничтожить точки восстановления и зашифровать виртуальные машины.
- Оцените последствия. Зафиксируйте простой, потерю данных, нарушение договоров, расходы на восстановление и допустимый остаточный риск.
- Разложите сценарий на техники ATT&CK. Выбирайте только подходящие платформы, техники и процедуры, а не всю матрицу.
- Свяжите техники с необходимыми контролями. Контроли можно взять из Annex A, отраслевых стандартов, внутренних архитектурных требований и законодательства.
- Определите телеметрию. Для каждого шага укажите журналы идентификации, EDR, операционных систем, облачных платформ, сетевых устройств, гипервизоров и системы резервного копирования.
- Создайте аналитику и сценарий реагирования. Аналитик должен понимать, как подтвердить событие, ограничить доступ, изолировать узел, сохранить доказательства и запустить восстановление.
- Проведите безопасную эмуляцию. Результат теста должен изменить правило обнаружения, конфигурацию защиты, план реагирования или оценку риска.
| Поле рабочего реестра | Что записывать |
|---|---|
| Risk ID | Идентификатор риска из ISMS |
| Asset scope | Сервисы, платформы и данные внутри сценария |
| ATT&CK version | Версия базы, по которой выполнено сопоставление |
| Technique ID | Техника или подтехника с учетом конкретной платформы |
| Necessary controls | Применимые контроли Annex A и дополнительные меры |
| Telemetry | Источники событий, обязательные поля и срок хранения |
| Detection | Правило SIEM, EDR-аналитика или корреляционный сценарий |
| Response | Инструкция реагирования и ответственные команды |
| Validation | Тест, дата запуска, результат и найденные пробелы |
| Risk owner | Руководитель, который принимает остаточный риск |
Такой реестр легко превратить в таблицу для аудита, backlog команды SOC, слой ATT&CK Navigator или машиночитаемый каталог для GRC-платформы. Главным объектом остается не техника ATT&CK, а риск для конкретного сервиса.
Пример со сценарием шифровальщика
Сценарий «защититься от шифровальщика» слишком расплывчат. Шифрование обычно завершает цепочку, которая включает кражу учетной записи, повышение привилегий, перемещение между узлами, отключение защитных механизмов и уничтожение средств восстановления. Защита должна разрывать несколько звеньев, а не ждать массовой перезаписи файлов.
Таблица ниже показывает возможное соответствие, а не официальную матрицу ISO и MITRE. Организация должна скорректировать набор контролей под собственную архитектуру, оценку рисков и обязательства.
| Действие нарушителя | Техника ATT&CK | Возможные контроли ISO/IEC 27001 | Что нужно доказать тестом |
|---|---|---|---|
| Вход с украденной учетной записью | T1078 Valid Accounts | A.5.15 управление доступом, A.5.16 управление идентификацией, A.5.17 аутентификационная информация, A.5.18 права доступа, A.8.5 безопасная аутентификация | MFA нельзя обойти штатным способом, лишние права удаляются, необычный вход создает расследуемый сигнал |
| Получение паролей и хешей | T1003 OS Credential Dumping | A.8.2 привилегированный доступ, A.8.5 безопасная аутентификация, A.8.7 защита от вредоносного ПО, A.8.15 журналирование, A.8.16 мониторинг | EDR видит доступ к хранилищам учетных данных, попытка блокируется или вызывает сигнал с нужным контекстом |
| Перемещение через RDP, SMB, WinRM или SSH | T1021 Remote Services | A.5.15 управление доступом, A.8.20 безопасность сетей, A.8.21 безопасность сетевых сервисов, A.8.22 сегментация сетей | Административные протоколы доступны только из разрешенных зон, удаленная сессия связывается с пользователем и исходным узлом |
| Остановка EDR или нарушение журналирования | T1685 Disable or Modify Tools | A.8.9 управление конфигурациями, A.8.15 журналирование, A.8.16 мониторинг, A.5.24 подготовка к управлению инцидентами, A.5.26 реагирование | Защита от вмешательства блокирует изменение или независимый канал сообщает о потере агента и прекращении телеметрии |
| Удаление снимков и резервных копий | T1490 Inhibit System Recovery | A.8.13 резервное копирование, A.8.14 резервирование средств обработки, A.5.29 безопасность во время нарушений, A.5.30 готовность ИКТ к непрерывности | Администратор рабочей среды не может удалить все копии, а команда восстанавливает сервис в заявленные сроки |
| Массовое шифрование данных | T1486 Data Encrypted for Impact | A.8.13 резервное копирование, A.8.14 резервирование, A.8.16 мониторинг, A.5.29 и A.5.30 | Система обнаруживает аномальное изменение файлов, ограничивает распространение и позволяет восстановить проверенную копию |
Резервирование и резервное копирование нельзя считать одной мерой. Репликация может быстро перенести удаление, повреждение или зашифрованное состояние на второй узел. Защита от T1490 требует отдельных административных учетных записей, изолированных или неизменяемых копий, контроля операций удаления и регулярного восстановления. Отчет об успешном создании копии не доказывает возможность вернуть сервис.
Аналитика также не должна зависеть от одной команды или одного имени процесса. Нарушитель может удалить теневые копии через системную утилиту, API гипервизора, консоль резервного копирования или облачный интерфейс. Надежная стратегия связывает несколько признаков, например получение привилегий, изменение политики хранения, удаление снимков, остановку агента, массовые операции с файлами и потерю связи с системой мониторинга.
Новая модель Detection Strategies в ATT&CK лучше подходит для такого подхода, чем старый список источников данных. Команда описывает не только нужный журнал, но и аналитическую гипотезу, последовательность событий, обязательные поля, допустимые исключения и действия аналитика. Наличие логов без проверенного правила обнаружения нельзя считать покрытием техники.
Где объединенная модель дает ложное чувство безопасности
Самая распространенная ошибка связана с процентом покрытия ATT&CK. Полная матрица включает разные платформы, типы инфраструктуры и способы действий. Часть техник неприменима к конкретной организации, часть трудно отличить от обычного администрирования, а одна техника может выполняться десятками процедур. Зеленая ячейка в Navigator часто означает только наличие одного правила, а не устойчивую защиту от всей техники.
Вторая ошибка возникает при сопоставлении одной техники с одним контролем. T1078 Valid Accounts касается не только MFA. Сценарий затрагивает жизненный цикл учетной записи, выдачу и отзыв прав, привилегированные роли, журналы входа, мониторинг аномалий и реагирование. Один контроль ISO, в свою очередь, может снижать риск сразу для десятков техник.
Третья ошибка состоит в превращении ATT&CK в линейную kill chain. Тактики ATT&CK не задают обязательный порядок действий. Нарушитель может возвращаться к разведке, снова получать учетные данные, менять способ закрепления и пропускать целые тактики. Для теста нужна реалистичная цепочка процедур, а не движение слева направо по колонкам.
Четвертая ошибка связана с сертификатом ISO/IEC 27001. Сертификация подтверждает соответствие ISMS требованиям стандарта в заявленной области и на основании аудиторской выборки. Сертификат не гарантирует отсутствие уязвимостей, не подтверждает покрытие всей инфраструктуры и не заменяет технические испытания. Перед оценкой поставщика нужно читать область сертификата и Statement of Applicability, а не только смотреть на логотип ISO.
Пятая ошибка возникает из-за устаревших идентификаторов. После выхода ATT&CK v19 старые таблицы продолжают ссылаться на T1562 Impair Defenses и прежнюю тактику Defense Evasion. Автоматический импорт свежего STIX-набора не исправит внутренние документы, правила SIEM и отчеты, где идентификаторы записаны вручную. Версию ATT&CK нужно хранить рядом с каждой связью и пересматривать сопоставление после крупных релизов.
| Показатель | Что измеряет | Плохая замена |
|---|---|---|
| Доля приоритетных сценариев, проверенных за период | Фактическую регулярность испытаний | Процент закрашенных техник ATT&CK |
| Доля тестов, которые создали ожидаемый сигнал | Работу телеметрии и аналитики | Количество правил SIEM |
| Время подтверждения и локализации сценария | Способность команды остановить ущерб | Число обработанных оповещений |
| Результат контрольного восстановления | Реальную готовность вернуть сервис и данные | Статус успешного резервного копирования |
| Количество просроченных пробелов с владельцами | Управление остаточным риском | Общее число найденных замечаний |
Рабочее объединение ISO/IEC 27001 и MITRE ATT&CK начинается не с глобальной матрицы, а с одного критичного сервиса. Опишите ущерб, соберите реалистичную цепочку техник, назначьте необходимые контроли, определите телеметрию, создайте аналитику и проведите безопасный тест. Если результат меняет конфигурацию, правило обнаружения, план реагирования или оценку риска, фреймворки усиливают защиту. Если работа заканчивается таблицей соответствий и цветным слоем Navigator, организация улучшила отчетность, но не доказала устойчивость инфраструктуры.
Вопросы и ответы
Чем MITRE ATT&CK отличается от ISO 27001?
ISO/IEC 27001 задает требования к системе управления информационной безопасностью, включая оценку рисков, ответственность, аудит и постоянное улучшение. MITRE ATT&CK описывает тактики, техники и процедуры, которые злоумышленники применяют во время реальных атак. ISO отвечает за управление защитой, а ATT&CK помогает наполнить защиту конкретными техническими сценариями.
Можно ли использовать MITRE ATT&CK вместо ISO 27001?
Нет. MITRE ATT&CK не определяет область действия системы безопасности, владельцев рисков, порядок внутреннего аудита, политику управления и критерии принятия остаточного риска. ATT&CK дополняет ISO/IEC 27001, но не заменяет систему управления информационной безопасностью.
Как связать техники ATT&CK с контролями ISO 27001?
Сначала нужно описать риск для конкретного сервиса, затем разложить возможную атаку на техники ATT&CK. После этого для каждой техники выбирают организационные и технические меры ISO/IEC 27001, источники телеметрии, правила обнаружения, сценарии реагирования и контрольные тесты. Прямое сопоставление всей матрицы ATT&CK со всеми мерами Annex A обычно создает громоздкий и быстро устаревающий документ.
Что такое Statement of Applicability в ISO 27001?
Statement of Applicability, или заявление о применимости, фиксирует выбранные организацией меры безопасности. Документ показывает, какие контроли применяются, почему компания выбрала конкретные меры, как они внедрены и по какой причине отдельные меры исключены. Statement of Applicability связывает оценку рисков с практической системой защиты.
Нужно ли покрывать все техники MITRE ATT&CK?
Нет. Полная матрица включает техники для разных платформ, архитектур и моделей нарушителя. Организации нужно выбирать техники, которые относятся к ее активам, технологиям и вероятным сценариям атак. Попытка покрыть всю матрицу расходует ресурсы и создает ложные показатели защищенности.
Как проверить, что техника ATT&CK действительно покрыта?
Одного правила SIEM или отметки в ATT&CK Navigator недостаточно. Команда должна получить нужную телеметрию, обнаружить тестовое действие, передать аналитику достаточно контекста, выполнить сценарий реагирования и подтвердить, что защитная мера снижает риск. Проверку проводят с помощью purple team, эмуляции атак или контролируемых тестовых событий.
Какие журналы нужны для работы с MITRE ATT&CK?
Набор зависит от инфраструктуры и выбранных техник. Обычно используют телеметрию EDR, журналы операционных систем, Active Directory, облачных платформ, средств удаленного доступа, сетевых устройств, гипервизоров, систем идентификации и резервного копирования. Для каждого правила нужно заранее определить обязательные поля, срок хранения и допустимые пробелы в данных.
Гарантирует ли сертификат ISO 27001 защиту от кибератак?
Нет. Сертификат подтверждает, что система управления информационной безопасностью соответствует требованиям стандарта в заявленной области. Сертификация не гарантирует отсутствие уязвимостей и не доказывает, что SOC обнаружит конкретную технику атаки. Для оценки защиты нужны технические тесты, анализ области сертификата и проверка применимых мер.
