В серверной уже крутится SIEM, аналитики строят карты атак по ATT&CK, а руководству всё равно не хватает ответа на простой вопрос: кто отвечает за инцидент, хранение логов и риск-процедуры. Именно на этом месте обычно и ломается спор про «старые стандарты» и «новую практику».

Какую проблему решаем

В профессиональной среде часто пытаются выбрать что-то одно: либо ISO/IEC 27001, либо ATT&CK. Но это ложная развилка. Стандарт отвечает за управление безопасностью, а ATT&CK — за описание поведения атакующего и работу с тактиками, техниками и процедурами.

Если смешать эти уровни, компания получает перекос. Техническая команда строит детекты, но не понимает, как хранить логи, кто владелец риска и как проверять поставщиков. Аудит пройден, но расследование инцидента рассыпается, потому что телеметрия неполная и сроки хранения слишком короткие.

Что подготовить

Для начала полезно честно разделить две плоскости. Первая — governance: политика, роли, ответственность, управление рисками, аудит, работа с подрядчиками, готовность к расследованию. Вторая — операционная безопасность: журналирование, корреляция событий, threat hunting, реагирование и настройка детектов.

Если у вас нет базовой карты процессов, ATT&CK будет выглядеть как красивая витрина. А без операционной части ISO/IEC 27001 останется набором регламентов, которые никто не связывает с реальными атаками.

Для удалённых сотрудников и команд, которые работают из кафе, аэропортов и отелей, отдельный слой приватности тоже важен. Один из практичных инструментов — средство для защищённой работы вне офиса, если нужно снизить риски в открытых сетях и не светить лишние данные в чужой инфраструктуре.

Пошаговые действия

один. Разведите роли и документы

Сначала определите, кто в компании отвечает за риски, кто — за логи, кто — за реагирование, а кто — за контроль поставщиков. Без этого даже хороший SOC начинает жить отдельно от управленческой модели.

два. Привяжите ATT&CK к реальным процессам

Не ограничивайтесь красивой матрицей на слайде. Для каждой техники атакующего проверьте, есть ли лог-источники, срок хранения, ответственный за детект и процедура проверки сработки.

три. Укрепите базовую видимость

Соберите централизованное журналирование, синхронизацию времени, требования к retention и контроль критичных источников. Если PowerShell, DNS или облачные журналы живут отдельно и недолго, расследование потом превратится в угадывание.

четыре. Свяжите инциденты с управлением

ISO/IEC 27001 нужен не ради галочки, а чтобы инциденты не растворялись между ИТ, безопасностью и подрядчиками. Если в процессе нет владельца, даже самый точный детект не дойдёт до исправления причины.

пять. Используйте ATT&CK как рабочий язык команды

Этот фреймворк помогает одинаково говорить о техниках, проверках и пробелах в защите. Он особенно полезен для threat hunting, adversary emulation и настройки правил обнаружения.

Если вы хотите отдельно разобрать практику журналирования и хранения следов, пригодится и материал о прикладном шифровании в .NET — он хорошо дополняет разговор о защите данных на уровне приложений.

Как проверить себя

Задайте команде пять вопросов. Есть ли у нас владелец каждого критичного риска? Понимаем ли мы, какие логи нужны для расследования? Хранится ли телеметрия достаточно долго? Привязаны ли детекты к реальным техникам атакующего? Есть ли процедура, которая превращает находку аналитика в управленческое решение?

Если на два-три вопроса ответ «нет» или «не знаем», организация живёт на разрозненных практиках, а не на цельной архитектуре.

Что делать, если не получилось

Если SOC есть, а управляемости нет — начните с простого. Назначьте владельцев процессов, опишите требования к журналам и срокам хранения, проверьте покрытие критичных систем и свяжите инциденты с регулярным пересмотром рисков.

Если у вас наоборот много регламентов, но мало техники, добавьте ATT&CK-мэппинг для ключевых сценариев атак и проверьте, можно ли по ним реально детектировать и расследовать инциденты. Так стандарт перестанет быть бумажным, а операционная защита — набором разрозненных настроек.

Практический чек-лист

  • Проверить, кто в компании владеет рисками, логами и реагированием.
  • Сверить список критичных источников телеметрии с реальным покрытием.
  • Убедиться, что журналы хранятся достаточно долго для расследования.
  • Привязать ключевые детекты к техникам ATT&CK, а не к общим тревогам.
  • Перекинуть выводы по инцидентам в пересмотр рисков и процедур.
  • Проверить, не живут ли безопасность, ИТ и подрядчики в разных процессах.
  • Для работы вне офиса выбрать инструмент, который помогает не светить данные в чужой сети.
Поделиться: