Фреймворк атак

Фреймворк атак выполняет декларативные событийно-управляемые атаки на активные сервисы поведения во время симуляции. Поведение атаки описывается в YAML, преобразуется в структурированные спецификации и на каждом такте симуляции вычисляется относительно нормализованного снимка состояния сервисов транспортных средств и RSU.

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

Включение атак

Конфигурации сценариев включают атаки с помощью списка attacks верхнего уровня:

attacks:
  - aim_server_response_jamming
  - aim_client_identity_spoofing

Каждое имя атаки разрешается в:

opencda/core/attack/adversary_framework/attacks/<attack-name>/config.yaml

При запуске сценария каждый YAML-файл загружается, преобразуется в AttackSpec, а затем - в объект времени выполнения Attack с помощью Attack.from_spec(...).

Интеграция со средой выполнения

Фреймворк вычисляется из основных циклов сценария. На каждом такте код сценария:

обновляет сервисы поведения транспортных средств и RSU,
создаёт SimulationSnapshot,
вызывает AttackManager.evaluate(...),
разрешает активные целевые сервисы через CavWorld.resolve_behavior_services.

Ниже показан общий процесс вычисления атаки на каждом такте.

Снимок, передаваемый во фреймворк атак, имеет следующую структуру:

@dataclass(frozen=True, slots=True)
class NodeSnapshot:
    node_id: str
    node_type: str
    service_states: dict[str, Any]

@dataclass(frozen=True, slots=True)
class SimulationSnapshot:
    tick: int
    vehicle_nodes: tuple[NodeSnapshot, ...]
    rsu_nodes: tuple[NodeSnapshot, ...]

service_states содержит последние выходные данные get_state() подключённых сервисов поведения с ключами по service_type.

Основные компоненты

`AttackManager`

AttackManager хранит предыдущий снимок и продвигает все настроенные атаки относительно текущего снимка. Он отвечает за:

проверку триггеров запуска и остановки атаки,
разрешение целевых сервисов для атак, которые должны выполняться,
выполнение активных этапов,
создание объектов AttackResult,
журналирование успешных результатов, остановок и сбоев.

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

`Attack`

Attack - объект времени выполнения, созданный из AttackSpec. Он хранит:

разобранную спецификацию,
состояние жизненного цикла во время выполнения,
упорядоченные среды выполнения этапов,
последние результаты каждого этапа.

Жизненный цикл по умолчанию:

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

`ConditionEvaluator`

Условия вычисляются на основе:

текущий и предыдущий SimulationSnapshot,
текущую среду выполнения атаки,
текущие среды выполнения этапов.

Поддерживаемые типы источников: snapshot, attack и stage.

`TargetResolver`

Сейчас для разрешения целей поддерживается одна стратегия - service_state_field. Средство разрешения:

считывает одно поле снимка,
нормализует его значение в один или несколько ID узлов,
разрешает активные сервисы поведения для этих ID узлов,
при необходимости фильтрует по service_type.

Встроенные этапы

Встроенные этапы автоматически регистрируются через AttackStageRegistry при импорте модуля фреймворка.

`sniffer`

Пассивный наблюдатель, записывающий выходные данные, возвращаемые соответствующими обработчиками возможностей.

Возможность по умолчанию: response.observe
Поддерживаемые возможности: request.observe, request.submit, response.observe, response.submit, command.submit, state.observe
Параметры отсутствуют

`dropper`

Заменяет выбранные выходные данные пустым пакетом или с заданной вероятностью отбрасывает элементы итерируемых выходных данных.

Возможность по умолчанию: response.submit
Поддерживаемые возможности: request.observe, request.submit, response.observe, response.submit, command.submit
Параметры: drop_rate (float в диапазоне [0.0, 1.0], по умолчанию 1.0), seed (необязательное начальное значение генератора)

`replayer`

Повторно воспроизводит предыдущие выходные данные, полученные для каждой соответствующей привязки сервиса и возможности.

Возможность по умолчанию: response.submit
Поддерживаемые возможности: request.observe, request.submit, response.observe, response.submit, command.submit
Параметры отсутствуют

`spoofer`

Изменяет выбранные поля внутри оболочек или полезной нагрузки TransportMessage.

Возможность по умолчанию: request.submit
Поддерживаемые возможности: request.submit, response.submit, command.submit
Параметры: обязательный список rewrites с полями path, operation и value для каждого правила

Возможности

Текущий общий словарь возможностей сервисов:

request.observe
request.submit
response.observe
response.submit
command.submit
state.observe

Этапы объявляют необходимые им возможности, а фреймворк сопоставляет их с картой capability_bindings каждого целевого сервиса.

Модель перехвата

Этапы не изменяют сам фреймворк. Вместо этого они временно оборачивают связанные методы, предоставляемые привязками возможностей сервисов поведения.

На практике встроенные этапы устанавливают перехватчики выходных данных на разрешённые экземпляры целевых сервисов, а затем удаляют их через deactivate() или при остановке атаки.

Результаты и журналирование

Фреймворк создаёт объекты AttackResult со следующими полями:

attack_name
status
reason
stage_history

Возможные состояния результата:

success
fail
stop

В условиях времени выполнения атак и этапов используются состояния жизненного цикла, например inactive, active, success, fail и stopped. Внутренне среда выполнения также содержит состояние STARTED, но при вычислении условий оно нормализуется в active.

В настоящее время для наблюдения за выполнением атак цикл сценария использует журналирование фреймворка.