модуль ara::idsm — Intrusion Detection System Manager

Intrusion Detection System Manager как центральная служба платформы регистрирует события безопасности от функциональных кластеров и приложений через стандартизированные экземпляры класса [SWS_AIDSM_10101] AUTOSAR_AP_EXP_SWArchitecture с. 124. Входящие сообщения могут дополняться временными метками и контекстными данными, фильтроваться и передаваться в виде квалифицированных событий безопасности авторизованным получателям [SWS_AIDSM_10800]. Подключение всех интерфейсов и ID событий требует согласованного моделирования через манифест AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification с. 257.

больше ›

Intrusion Detection System Manager (IdsM) функционирует в AUTOSAR Adaptive Platform как центральный демон-ориентированный Functional Cluster для агрегации, фильтрации и оценки событий безопасности AUTOSAR_AP_EXP_PlatformDesign с. 95. Как функциональные кластеры, такие как Communication Management, Firewall и Diagnostic Management, так и прикладные компоненты потокобезопасно сообщают об инцидентах безопасности в IdsM через стандартизированные экземпляры класса [SWS_AIDSM_10101] AUTOSAR_AP_SWS_IntrusionDetectionSystemManager с. 13.

Контекстная диаграмма: встраивание демона IdsM в качестве центрального приемника событий безопасности из функциональных кластеров и приложений. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager с. 13.

Передача сообщений о событиях через ReportEvent поддерживает различные уровни детализации: от простых счетчиков и явных меток времени до неверсионированных или версионированных контекстных данных [SWS_AIDSM_10302], [SWS_AIDSM_10307]. Для динамического обогащения приложения могут подключаться через [SWS_AIDSM_10400] и [SWS_AIDSM_10500] в качестве провайдеров меток времени или дополнительных байтов контекста AUTOSAR_AP_EXP_SWArchitecture с. 122. После обработки внутренними цепочками фильтрации IdsM перенаправляет квалифицированные события зарегистрированным получателям через функции обратного вызова оповещений класса [SWS_AIDSM_10800] [SWS_AIDSM_10807].

Диаграмма последовательности: синхронная передача сообщения о событии безопасности сенсорным компонентом через EventReporter. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 232, [SWS_AIDSM_10101].

Конфигурация портов и сопоставление определений событий выполняются через стандартизированные элементы метамодели в манифесте AUTOSAR_AP_TPS_ManifestSpecification с. 257. Поведение отправки сообщений для отдельных событий также можно контролировать во время выполнения через [SWS_AIDSM_10600], при этом недопустимые ID событий сигнализируются через домен ошибок [SWS_AIDSM_10706] с кодом ошибки kUnknownEventId [SWS_AIDSM_10204], [SWS_AIDSM_10602].

больше ›

Роль и системные границы Intrusion Detection System Manager

Intrusion Detection System Manager (IdsM) образует центральный экземпляр платформы для регистрации, предварительной фильтрации и квалификации событий безопасности (Security Events) на AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_PlatformDesign с. 95. В соответствии с требованиями кибербезопасности стандарта ISO/SAE 21434 IdsM функционирует на блоках управления на базе POSIX как автономная фоновая служба (daemon-based Functional Cluster) AUTOSAR_AP_EXP_SWArchitecture с. 124. Его основная задача заключается в сборе аномалий и потенциальных попыток атак, их оценке на основе сконфигурированных правил, таких как ограничения частоты или пороговые значения, и сведении их в квалифицированные события безопасности (Qualified Security Events) AUTOSAR_EXP_SWArchitecture с. 97.

Архитектура IdsM рассчитана на интероперабельность с другими функциональными кластерами. Службы платформы, такие как Communication Management AUTOSAR_AP_SWS_CommunicationManagement с. 34, Firewall AUTOSAR_AP_SWS_Firewall с. 11 и Diagnostic Management AUTOSAR_AP_SWS_Diagnostics с. 67, а также специфичные для приложений процессы выступают в роли датчиков безопасности AUTOSAR_AP_SWS_IntrusionDetectionSystemManager с. 13. Следующий обзор иллюстрирует интеграцию демона IdsM в среду выполнения Adaptive Platform.

Контекстная диаграмма: встраивание демона IdsM в качестве центрального приемника событий безопасности из функциональных кластеров и приложений. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager с. 13, AUTOSAR_AP_EXP_PlatformDesign с. 95.

Передача сообщений о событиях через EventReporter и формы взаимодействия

Основной входной интерфейс для передачи сведений об инцидентах безопасности реализован классом [SWS_AIDSM_10101]. Передающий узел инстанцирует этот класс с указанием заданного порта с помощью ara::core::InstanceSpecifier потокобезопасным образом через конструктор [SWS_AIDSM_10301]. За счет этого устанавливается привязка к определенному в манифесте SecurityEventReportInterface AUTOSAR_AP_TPS_ManifestSpecification с. 257. Непосредственная передача выполняется через перегруженные варианты синхронного метода ReportEvent, каждый из которых может выполняться потокобезопасно [SWS_AIDSM_10302].

В зависимости от типа события и доступных данных датчиков интерфейс предоставляет дифференцированные формы передачи сообщений. Базовый метод передает только количество повторений типа [SWS_AIDSM_10203] (значение по умолчанию 1) без дополнительных метаданных [SWS_AIDSM_10302]. Для критичных ко времени процессов можно напрямую передать специфичную для датчика временную метку типа [SWS_AIDSM_10202] [SWS_AIDSM_10303]. Кроме того, неизменяемые полезные данные могут передаваться в виде байтового диапазона типа [SWS_AIDSM_10201] как отдельно [SWS_AIDSM_10304], так и в комбинации с временной меткой [SWS_AIDSM_10305]. Для структурированных форматов событий существуют перегрузки с версионированными контекстными данными типа [SWS_AIDSM_10206], которые представляют собой пару значений из диапазона контекстных данных и 16-битного индикатора версии [SWS_AIDSM_10306], опционально дополненную явной временной меткой [SWS_AIDSM_10307].

Типичным сценарием для этого пути передачи сообщений является отбрасывание недопустимых сетевых пакетов стеком TCP/IP и Firewall: операционная система сообщает о заблокированных пакетах демону Firewall, который затем незамедлительно вызывает ReportEvent AUTOSAR_AP_EXP_SWArchitecture с. 232. Следующая диаграмма последовательности иллюстрирует этот синхронный процесс отправки сообщений.

Диаграмма последовательности: синхронная передача сообщения о событии безопасности сенсорным компонентом через EventReporter. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 232, [SWS_AIDSM_10101], [SWS_AIDSM_10302].

Расширенные контекстные данные и временные метки через интерфейсы провайдеров

Чтобы не перегружать сообщающие процессы ресурсоемкими запросами времени или статической контекстной информацией, архитектура поддерживает инверсию потока управления через интерфейсы провайдеров AUTOSAR_AP_EXP_SWArchitecture с. 122. Приложения могут выступать в роли поставщиков меток времени, наследуясь от абстрактного класса [SWS_AIDSM_10400]. После инстанцирования через конструктор [SWS_AIDSM_10401] приложение активирует службу с помощью Offer() [SWS_AIDSM_10408]. С этого момента IdsM при необходимости может вызывать чисто виртуальный метод GetTimestamp() для запроса текущего значения времени [SWS_AIDSM_10407]. Предоставление завершается с помощью StopOffer() [SWS_AIDSM_10409].

Аналогичным образом базовый класс [SWS_AIDSM_10500] обеспечивает динамическое обогащение или модификацию контекстных данных. Конструктор ожидает, помимо InstanceSpecifier, указание размера дополнительных байтов, а также смещение для исходных контекстных данных [SWS_AIDSM_10501]. После разблокирования посредством Offer() [SWS_AIDSM_10507] демон IdsM при поступлении события вызывает метод ModifyContextData [SWS_AIDSM_10509]. При этом передается доступный для записи байтовый диапазон, в который приложение записывает измененные данные и возвращает результирующий размер данных в виде ara::core::Result<std::size_t> [SWS_AIDSM_10509]. С помощью StopOffer() прием дальнейших запросов на модификацию отключается [SWS_AIDSM_10508].

Диаграмма последовательности: жизненный цикл и процесс инверсии управления при обогащении событий безопасности через TimestampProvider и ContextDataProvider. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 122, [SWS_AIDSM_10408], [SWS_AIDSM_10509].

Прием квалифицированных событий безопасности и управление режимами работы

После того как IdsM обработает входящие события и квалифицирует их на основе своих правил фильтрации, авторизованные Adaptive Applications могут быть проинформированы о наличии квалифицированного события AUTOSAR_AP_EXP_SWArchitecture с. 123. Для этого служит класс [SWS_AIDSM_10800], который инстанцируется через свой специфичный для порта конструктор [SWS_AIDSM_10801]. После вызова Offer() [SWS_AIDSM_10808] IdsM пересылает оповещения приложению, вызывая соответствующий callback. Если доступны неверсионированные данные, вызов выполняется через OnEventQualification с опциональным контекстом и опциональной временной меткой [SWS_AIDSM_10807]. При наличии версионированных контекстных данных демон обращается к перегруженному интерфейсу [SWS_AIDSM_10810]. Оповещение может быть прекращено с помощью StopOffer() [SWS_AIDSM_10809].

Диаграмма последовательности: прием квалифицированных событий безопасности реагирующим приложением через QualifiedEventsReceiver. Источники: AUTOSAR_AP_EXP_SWArchitecture с. 123, [SWS_AIDSM_10801], [SWS_AIDSM_10808], [SWS_AIDSM_10807].

Для динамического управления поведением отправки сообщений для каждого события существует класс [SWS_AIDSM_10600], который инициализируется через конструктор [SWS_AIDSM_10601]. С помощью GetReportingMode можно запросить текущий режим для ID события типа [SWS_AIDSM_10205] [SWS_AIDSM_10602]. Посредством SetReportingMode режим можно изменять во время выполнения [SWS_AIDSM_10603]. Перечисление [SWS_AIDSM_10207] определяет доступные режимы, которые варьируются от полного отключения (kOff), стандартной и детальной регистрации (kBrief, kDetailed) до целенаправленного обхода внутренних цепочек фильтрации (kBriefBypassingFilters, kDetailedBypassingFilters) [SWS_AIDSM_10207].

Диаграмма состояний: режимы отправки сообщений и фильтрации при обработке событий согласно ReportingModeType. Источники: [SWS_AIDSM_10207], [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Моделирование манифеста, привязка портов и развертывание

Интеграция всех интерфейсов в общую систему осуществляется декларативно через манифест AUTOSAR. Все интерфейсы портов, связанные с IdsM, наследуются в метамодели от общего базового класса IdsmAbstractPortInterface AUTOSAR_AP_TPS_ManifestSpecification с. 257. Отправка сообщений моделируется через SecurityEventReportInterface, который связывается с формальным SecurityEventDefinition через SecurityEventReportToSecurityEventDefinitionMapping AUTOSAR_AP_TPS_ManifestSpecification с. 146. Это явное разделение позволяет повторно использовать стандартизированные программные компоненты и назначать специфичные для проекта ID событий только на этапе конфигурации TPS_ManifestSpecification с. 146.

На уровне развертывания различные провайдеры и приемники отображаются как UploadableDeploymentElement TPS_ManifestSpecification с. 881. К ним относятся IdsmTimestampProviderMapping AUTOSAR_AP_TPS_ManifestSpecification с. 664, IdsmContextProviderMapping AUTOSAR_AP_TPS_ManifestSpecification с. 665, IdsmReportingModeProviderMapping AUTOSAR_AP_TPS_ManifestSpecification с. 667, а также IdsmQualifiedEventReceiverMapping AUTOSAR_AP_TPS_ManifestSpecification с. 669. Эти метаклассы связывают модульный экземпляр платформы IdsPlatformInstantiation с соответствующим процессом (Process) и целевым портом (PPortPrototype или RPortPrototype) TPS_ManifestSpecification с. 664. Для функциональных кластеров, кроме того, существует специальное сопоставление FunctionalClusterToSecurityEventDefinitionMapping, позволяющее корректно сопоставлять события платформы без прямой привязки к процессу AUTOSAR_AP_TPS_ManifestSpecification с. 873.

Поведение при ошибках и обработка диагностики

Ошибочные ситуации внутри модуля IdsM обрабатываются в соответствии со стандартизированной концепцией обработки ошибок AUTOSAR через домен ошибок [SWS_AIDSM_10706]. Ссылка на него получается через глобальную функцию GetIdsmErrorDomain() [SWS_AIDSM_10702]. Конкретные ошибки API представлены перечислением [SWS_AIDSM_10204] (псевдоним [SWS_AIDSM_10707]). Если, например, при запросе или установке режима отправки сообщений возникает неизвестный ID события, операции GetReportingMode и SetReportingMode возвращают ошибочный ara::core::Result с кодом IdsmErrc::kUnknownEventId [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Для преобразования в структурированные объекты ошибок служит вспомогательная функция MakeErrorCode [SWS_AIDSM_10703]. Домен ошибок реализует интерфейсы для запроса имени домена [SWS_AIDSM_10710] и описательного текстового сообщения [SWS_AIDSM_10711]. Если в системе активированы исключения, код ошибки можно с помощью ThrowAsException [SWS_AIDSM_10712] сгенерировать в виде исключения типа [SWS_AIDSM_10704] (псевдоним [SWS_AIDSM_10708]), конструктор которого инкапсулирует базовый ErrorCode [SWS_AIDSM_10705].

Дополнительные подробные свидетельства и связь со спецификацией

В приведенном ниже перечне обобщены основные документы спецификации и архитектурные разделы модуля:

• Вход событий и отправка сообщений датчиками: спецификации [SWS_AIDSM_10101] и от [SWS_AIDSM_10302] до [SWS_AIDSM_10307] определяют сигнатуру C++ для EventReporter. Архитектурное встраивание через датчики платформы представлено в AUTOSAR_AP_SWS_IntrusionDetectionSystemManager с. 13 и AUTOSAR_AP_EXP_SWArchitecture с. 121.
• Внутриплатформенная интеграция: зависимости и паттерны использования других функциональных кластеров, таких как Communication Management (AUTOSAR_AP_SWS_CommunicationManagement с. 34), Firewall (AUTOSAR_AP_SWS_Firewall с. 11) и Diagnostic Management (AUTOSAR_AP_SWS_Diagnostics с. 67), подтверждают универсальную роль IdsM как сборщика данных безопасности.
• Провайдеры дополнительных данных и меток времени: спецификации [SWS_AIDSM_10400] и [SWS_AIDSM_10500] регламентируют шаблон предоставления временных меток и модификаций контекста, дополненный архитектурной схемой AUTOSAR_AP_EXP_SWArchitecture с. 122.
• Прием квалифицированных событий и рабочие режимы: требования [SWS_AIDSM_10800] и [SWS_AIDSM_10600] описывают исходящую коммуникацию и конфигурацию времени выполнения, проиллюстрированные в AUTOSAR_AP_EXP_SWArchitecture с. 123.
• Моделирование манифеста и развертывания: правила метамодели в AUTOSAR_AP_TPS_ManifestSpecification с. 257, а также сопоставления развертывания от AUTOSAR_AP_TPS_ManifestSpecification с. 664 до AUTOSAR_AP_TPS_ManifestSpecification с. 669 обеспечивают согласованное инстанцирование и подключение на этапах проектирования и загрузки.
• Обработка ошибок: определения [SWS_AIDSM_10204] и [SWS_AIDSM_10706] образуют фундамент обработки ошибок при недопустимых идентификаторах событий.