Регламент цифровой операционной устойчивости (Digital Operational Resilience Act, DORA) начал применяться во всём Европейском союзе в январе 2025 года. Первый год финансовые организации потратили преимущественно на управленческую работу: создавали механизмы контроля рисков, проверяли сторонних поставщиков, меняли договорные условия и описывали порядок эскалации инцидентов. На втором году одних документов уже мало. Регуляторам нужны доказательства практического исполнения DORA, качества анализа инцидентов в сфере информационно-коммуникационных технологий (Information and Communication Technology, ICT) и действенности надзора за ICT-рисками.
Статья 9, девятое по счёту положение DORA, предписывает непрерывно наблюдать за безопасностью и работой ICT-среды, управлять её эксплуатацией и применять процессы, ограничивающие ущерб от ICT-рисков. Инвентаризация активов отвечает на вопрос, какими системами владеет или управляет организация. Конфигурационные записи описывают предполагаемые связи, журналы безопасности и телеметрия конечных устройств дают подробности о наблюдаемых узлах. Но между проектной схемой и реальной сетью часто лежит белое пятно: устаревшая инфраструктура, специализированные устройства, неуправляемое оборудование и системы, где конечная телеметрия ограничена либо вовсе недоступна.
Именно в таких разрывах остаются следы эксплуатации уязвимостей, несанкционированных соединений и продвижения по цепочке атаки. Адаптивные угрозы, действующие со скоростью систем искусственного интеллекта, способны искать слепые зоны быстрее, чем аналитик успевает сопоставить разрозненные журналы. Поэтому центру управления безопасностью (Security Operations Center, SOC) необходимо видеть фактические коммуникации: кто с кем связался, когда это произошло, какой протокол использовался, куда был направлен трафик и сколько данных передано. DORA не предписывает конкретный набор защитных продуктов, однако непрерывный контроль без такой видимости трудно подтвердить на практике.
Средства обнаружения и реагирования на сетевые угрозы (Network Detection and Response, NDR) превращают трафик в структурированные сведения на уровне протоколов. Непрерывное наблюдение позволяет построить базовую модель обычного поведения, учитывать время соединений, объём трафика и направление обмена, а затем замечать отклонения. Допустим, приложение маршрутизации платежей регулярно обращается к внешней службе кредитной оценки. Если ночью оно внезапно начинает интенсивно связываться с незнакомыми внутренними узлами, сетевые данные покажут перемену, даже когда собственный журнал приложения ничего подозрительного не записал.
Следующая за ней статья 10 требует быстро обнаруживать аномальную активность, проблемы производительности сети и связанные с ними ICT-инциденты, а также заранее устанавливать пороги запуска реагирования. Проблема SOC обычно не в недостатке предупреждений, а в их количестве. Поток уведомлений перегружает аналитиков и маскирует действительно связанные события. Система обнаружения и реагирования на конечных устройствах (Endpoint Detection and Response, EDR) может найти подозрительный процесс, а система управления идентификацией — сомнительный вход. Сетевые сведения показывают, общались ли затронутые машины, по каким протоколам и что произошло после входа.
В трафике могут сохраниться признаки связи с командно-контрольной инфраструктурой, разведки внутри сети, бокового перемещения и передачи данных. Такие следы остаются полезными, когда журналы отдельных систем неполны, отключены или уже очищены атакующим. Вместо ручной сборки картины из изолированных источников аналитик получает коррелированные доказательства и может оценить масштаб инцидента, затронутые системы и последствия для работы организации. Для атак, развивающихся со скоростью ИИ, разница между отдельным сигналом и связной хронологией измеряется уже не удобством расследования, а временем до локализации.
Эта скорость нужна и для исполнения статьи 19 DORA. Первичное уведомление следует отправить как можно раньше, но не позднее четырёх часов после классификации события как крупного ICT-инцидента и не позднее 24 часов после того, как организация узнала о нём. За этот срок группе реагирования приходится пройти через сложную IT-среду, найти поражённые системы, восстановить ход атаки, отсечь посторонние или несанкционированные соединения, оценить масштаб и последствия, а затем собрать требуемые регламентом сведения. Сетевая хронология сокращает время на поиск, хотя сама по себе не заменяет процедуру классификации и отчётности.
Статьи 28–30 посвящены рискам сторонних ICT-поставщиков и договорам с ними. Контракт фиксирует разрешённый доступ, границы работы и ожидаемый объём действий провайдера. Сеть показывает, что происходит в действительности: какие программные пакеты используются, куда ведут туннели, как работают интеграции через интерфейсы прикладного программирования (Application Programming Interface, API), с какими внутренними системами установлены соединения и проходят ли данные по утверждённым маршрутам. Это позволяет заметить как разрешённые операции, так и пути, которых в документации нет.
Особенно показателен сценарий с похищенными учётными данными доверенного поставщика. Формально они остаются действительными и авторизованными, поэтому обычная проверка доступа может не увидеть нарушения. Поведение, однако, меняется: соединения возникают в другое время, используются непривычные протоколы, растёт объём передачи либо появляются обращения к системам за пределами согласованной области. NDR позволяет финансовой организации наблюдать это внутри собственной инфраструктуры, не полагаясь исключительно на отчёты провайдера. Договор не ответит, с какими узлами сейчас общается подключение и соответствует ли фактический трафик утверждённой схеме.
Corelight Network Defense предлагает NDR-платформу, данные которой компания описывает как открытые, прозрачные и объяснимые. По заявлению Corelight, сохранение структурированного сетевого контекста помогает обнаруживать уклоняющиеся от контроля угрозы, сокращать время разбора предупреждений и применять агентный искусственный интеллект в SOC. Более полный набор сведений предназначен и для расследований, и для систем ИИ: аналитики могут проверять выводы, восстанавливать последовательность действий и связывать события без опоры на ограниченные метаданные. Практическая проверка готовности к DORA в таком случае сводится к жёсткому вопросу: «Есть ли у SOC доказательства, необходимые для реагирования на атаку и её локализации?»
Изображение носит иллюстративный характер
Статья 9, девятое по счёту положение DORA, предписывает непрерывно наблюдать за безопасностью и работой ICT-среды, управлять её эксплуатацией и применять процессы, ограничивающие ущерб от ICT-рисков. Инвентаризация активов отвечает на вопрос, какими системами владеет или управляет организация. Конфигурационные записи описывают предполагаемые связи, журналы безопасности и телеметрия конечных устройств дают подробности о наблюдаемых узлах. Но между проектной схемой и реальной сетью часто лежит белое пятно: устаревшая инфраструктура, специализированные устройства, неуправляемое оборудование и системы, где конечная телеметрия ограничена либо вовсе недоступна.
Именно в таких разрывах остаются следы эксплуатации уязвимостей, несанкционированных соединений и продвижения по цепочке атаки. Адаптивные угрозы, действующие со скоростью систем искусственного интеллекта, способны искать слепые зоны быстрее, чем аналитик успевает сопоставить разрозненные журналы. Поэтому центру управления безопасностью (Security Operations Center, SOC) необходимо видеть фактические коммуникации: кто с кем связался, когда это произошло, какой протокол использовался, куда был направлен трафик и сколько данных передано. DORA не предписывает конкретный набор защитных продуктов, однако непрерывный контроль без такой видимости трудно подтвердить на практике.
Средства обнаружения и реагирования на сетевые угрозы (Network Detection and Response, NDR) превращают трафик в структурированные сведения на уровне протоколов. Непрерывное наблюдение позволяет построить базовую модель обычного поведения, учитывать время соединений, объём трафика и направление обмена, а затем замечать отклонения. Допустим, приложение маршрутизации платежей регулярно обращается к внешней службе кредитной оценки. Если ночью оно внезапно начинает интенсивно связываться с незнакомыми внутренними узлами, сетевые данные покажут перемену, даже когда собственный журнал приложения ничего подозрительного не записал.
Следующая за ней статья 10 требует быстро обнаруживать аномальную активность, проблемы производительности сети и связанные с ними ICT-инциденты, а также заранее устанавливать пороги запуска реагирования. Проблема SOC обычно не в недостатке предупреждений, а в их количестве. Поток уведомлений перегружает аналитиков и маскирует действительно связанные события. Система обнаружения и реагирования на конечных устройствах (Endpoint Detection and Response, EDR) может найти подозрительный процесс, а система управления идентификацией — сомнительный вход. Сетевые сведения показывают, общались ли затронутые машины, по каким протоколам и что произошло после входа.
В трафике могут сохраниться признаки связи с командно-контрольной инфраструктурой, разведки внутри сети, бокового перемещения и передачи данных. Такие следы остаются полезными, когда журналы отдельных систем неполны, отключены или уже очищены атакующим. Вместо ручной сборки картины из изолированных источников аналитик получает коррелированные доказательства и может оценить масштаб инцидента, затронутые системы и последствия для работы организации. Для атак, развивающихся со скоростью ИИ, разница между отдельным сигналом и связной хронологией измеряется уже не удобством расследования, а временем до локализации.
Эта скорость нужна и для исполнения статьи 19 DORA. Первичное уведомление следует отправить как можно раньше, но не позднее четырёх часов после классификации события как крупного ICT-инцидента и не позднее 24 часов после того, как организация узнала о нём. За этот срок группе реагирования приходится пройти через сложную IT-среду, найти поражённые системы, восстановить ход атаки, отсечь посторонние или несанкционированные соединения, оценить масштаб и последствия, а затем собрать требуемые регламентом сведения. Сетевая хронология сокращает время на поиск, хотя сама по себе не заменяет процедуру классификации и отчётности.
Статьи 28–30 посвящены рискам сторонних ICT-поставщиков и договорам с ними. Контракт фиксирует разрешённый доступ, границы работы и ожидаемый объём действий провайдера. Сеть показывает, что происходит в действительности: какие программные пакеты используются, куда ведут туннели, как работают интеграции через интерфейсы прикладного программирования (Application Programming Interface, API), с какими внутренними системами установлены соединения и проходят ли данные по утверждённым маршрутам. Это позволяет заметить как разрешённые операции, так и пути, которых в документации нет.
Особенно показателен сценарий с похищенными учётными данными доверенного поставщика. Формально они остаются действительными и авторизованными, поэтому обычная проверка доступа может не увидеть нарушения. Поведение, однако, меняется: соединения возникают в другое время, используются непривычные протоколы, растёт объём передачи либо появляются обращения к системам за пределами согласованной области. NDR позволяет финансовой организации наблюдать это внутри собственной инфраструктуры, не полагаясь исключительно на отчёты провайдера. Договор не ответит, с какими узлами сейчас общается подключение и соответствует ли фактический трафик утверждённой схеме.
Corelight Network Defense предлагает NDR-платформу, данные которой компания описывает как открытые, прозрачные и объяснимые. По заявлению Corelight, сохранение структурированного сетевого контекста помогает обнаруживать уклоняющиеся от контроля угрозы, сокращать время разбора предупреждений и применять агентный искусственный интеллект в SOC. Более полный набор сведений предназначен и для расследований, и для систем ИИ: аналитики могут проверять выводы, восстанавливать последовательность действий и связывать события без опоры на ограниченные метаданные. Практическая проверка готовности к DORA в таком случае сводится к жёсткому вопросу: «Есть ли у SOC доказательства, необходимые для реагирования на атаку и её локализации?»
