módulo ara::idsm — Intrusion Detection System Manager

O Intrusion Detection System Manager coleta, como serviço central da plataforma, eventos relevantes para a segurança provenientes de clusters funcionais e aplicações por meio de instâncias padronizadas da classe [SWS_AIDSM_10101] AUTOSAR_AP_EXP_SWArchitecture p. 124. Mensagens recebidas podem ser enriquecidas com carimbos de data/hora e dados de contexto, filtradas e encaminhadas como eventos de segurança qualificados para destinatários autorizados [SWS_AIDSM_10800]. A integração de todas as interfaces e IDs de eventos exige uma modelagem consistente por meio do manifesto AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification p. 257.

mais ›

O Intrusion Detection System Manager (IdsM) atua na AUTOSAR Adaptive Platform como um Functional Cluster central baseado em daemon para agregação, filtragem e avaliação de eventos relevantes para a segurança AUTOSAR_AP_EXP_PlatformDesign p. 95. Tanto clusters funcionais como Communication Management, Firewall e Diagnostic Management quanto componentes específicos da aplicação reportam incidentes de segurança com segurança para threads (thread-safe) via instâncias padronizadas da classe [SWS_AIDSM_10101] ao IdsM AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

Diagrama de contexto: Incorporação do daemon do IdsM como destino central para eventos de segurança originários de clusters funcionais e aplicações. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

A notificação de eventos via ReportEvent suporta níveis de detalhamento variáveis, desde contadores simples e carimbos de data/hora explícitos até dados de contexto não versionados ou versionados [SWS_AIDSM_10302], [SWS_AIDSM_10307]. Para enriquecimento dinâmico, aplicações podem ser integradas via [SWS_AIDSM_10400] e [SWS_AIDSM_10500] como provedores de carimbos de data/hora ou bytes de contexto adicionais AUTOSAR_AP_EXP_SWArchitecture p. 122. Após a avaliação de cadeias de filtros internas, o IdsM encaminha eventos qualificados para destinatários registrados por meio de callbacks de notificação da classe [SWS_AIDSM_10800] [SWS_AIDSM_10807].

Diagrama de sequência: notificação síncrona de um evento de segurança por um componente de sensor via EventReporter. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101].

A configuração das portas e a atribuição de definições de eventos ocorrem por meio de elementos padronizados do metamodelo no manifesto AUTOSAR_AP_TPS_ManifestSpecification p. 257. O comportamento de notificação de eventos individuais também pode ser controlado em tempo de execução via [SWS_AIDSM_10600], sendo que IDs de eventos inválidos são sinalizados através do domínio de erros [SWS_AIDSM_10706] com o código de erro kUnknownEventId [SWS_AIDSM_10204], [SWS_AIDSM_10602].

mais ›

Função e limites de sistema do Intrusion Detection System Manager

O Intrusion Detection System Manager (IdsM) constitui a instância central da plataforma para aquisição, pré-filtragem e qualificação de eventos relevantes para a segurança (Security Events) em uma AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_PlatformDesign p. 95. De acordo com os requisitos de cibersegurança da ISO/SAE 21434, o IdsM atua em ECUs baseadas em POSIX como um serviço de segundo plano autônomo (daemon-based Functional Cluster) AUTOSAR_AP_EXP_SWArchitecture p. 124. Sua tarefa principal consiste em coletar anomalias e potenciais tentativas de ataque, avaliá-las com base em regras configuradas, tais como limites de taxa ou valores de limiar, e consolidá-las em eventos de segurança qualificados (Qualified Security Events) AUTOSAR_EXP_SWArchitecture p. 97.

A arquitetura do IdsM foi concebida para interoperabilidade com outros clusters funcionais. Serviços de plataforma como Communication Management AUTOSAR_AP_SWS_CommunicationManagement p. 34, Firewall AUTOSAR_AP_SWS_Firewall p. 11 e Diagnostic Management AUTOSAR_AP_SWS_Diagnostics p. 67, bem como processos específicos da aplicação, atuam como sensores de segurança AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13. A visão geral a seguir ilustra a integração do daemon do IdsM no ambiente de tempo de execução da Adaptive Platform.

Diagrama de contexto: integração do daemon do IdsM como coletor central para eventos de segurança a partir de clusters funcionais e aplicações. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13, AUTOSAR_AP_EXP_PlatformDesign p. 95.

Notificação de eventos via EventReporter e formas de interação

A interface de entrada primária para a transmissão de incidentes de segurança é implementada pela classe [SWS_AIDSM_10101]. Uma unidade notificadora instancia essa classe especificando uma porta definida por meio de ara::core::InstanceSpecifier de forma thread-safe através do construtor [SWS_AIDSM_10301]. Dessa forma, é estabelecida a conexão com o SecurityEventReportInterface definido no manifesto AUTOSAR_AP_TPS_ManifestSpecification p. 257. A transmissão propriamente dita ocorre por meio de variantes sobrecarregadas do método síncrono ReportEvent, as quais podem ser executadas, cada uma, de forma thread-safe [SWS_AIDSM_10302].

Dependendo do tipo de evento e dos dados de sensores disponíveis, a interface oferece formas de notificação graduadas. O método básico transmite apenas uma contagem de repetições do tipo [SWS_AIDSM_10203] (valor padrão 1) sem metadados adicionais [SWS_AIDSM_10302]. Para processos críticos em termos de tempo, um timestamp específico do sensor do tipo [SWS_AIDSM_10202] pode ser fornecido diretamente [SWS_AIDSM_10303]. Além disso, dados úteis imutáveis podem ser passados como span de bytes do tipo [SWS_AIDSM_10201], seja isoladamente [SWS_AIDSM_10304] ou combinados com timestamp [SWS_AIDSM_10305]. Para formatos estruturados de eventos, existem sobrecargas com dados de contexto versionados do tipo [SWS_AIDSM_10206], que representam um par de valores composto por span de dados de contexto e um indicador de versão de 16 bits [SWS_AIDSM_10306], opcionalmente complementado por um timestamp explícito [SWS_AIDSM_10307].

Um cenário típico para esse caminho de notificação é o descarte de pacotes de rede inválidos pela pilha TCP/IP e pela Firewall: o sistema operacional notifica pacotes bloqueados ao daemon da Firewall, que em seguida chama imediatamente ReportEvent AUTOSAR_AP_EXP_SWArchitecture p. 232. O diagrama de sequência a seguir ilustra esse processo de notificação síncrona.

Diagrama de sequência: notificação síncrona de um evento de segurança por um componente de sensor via EventReporter. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101], [SWS_AIDSM_10302].

Dados de contexto estendidos e timestamps via interfaces de provider

Para não sobrecarregar os processos notificadores com consultas de tempo complexas ou informações estáticas de contexto, a arquitetura suporta uma inversão de fluxo de controle por meio de interfaces de provider AUTOSAR_AP_EXP_SWArchitecture p. 122. As aplicações podem atuar como provedores de serviço de timestamp derivando da classe abstrata [SWS_AIDSM_10400]. Após a instanciação por meio do construtor [SWS_AIDSM_10401], a aplicação ativa o serviço com Offer() [SWS_AIDSM_10408]. A partir desse momento, o IdsM pode invocar, quando necessário, o método virtual puro GetTimestamp() para consultar o valor de tempo atual [SWS_AIDSM_10407]. A disponibilização é encerrada com StopOffer() [SWS_AIDSM_10409].

De modo análogo, a classe base [SWS_AIDSM_10500] possibilita o enriquecimento ou a modificação dinâmica de dados de contexto. O construtor espera, além do InstanceSpecifier, a especificação de tamanho de bytes adicionais bem como o offset para os dados de contexto originais [SWS_AIDSM_10501]. Após a liberação por Offer() [SWS_AIDSM_10507], o daemon do IdsM invoca o método ModifyContextData na ocorrência do evento [SWS_AIDSM_10509]. Nesse processo, é passado um span de bytes gravável, no qual a aplicação grava dados modificados e retorna o tamanho de dados resultante como ara::core::Result<std::size_t> [SWS_AIDSM_10509]. Com StopOffer(), o recebimento de outras solicitações de modificação é desativado [SWS_AIDSM_10508].

Diagrama de sequência: ciclo de vida e fluxo de inversão de controle no enriquecimento de eventos de segurança via TimestampProvider e ContextDataProvider. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 122, [SWS_AIDSM_10408], [SWS_AIDSM_10509].

Recepção de eventos de segurança qualificados e controle de operação

Após o IdsM processar os eventos recebidos e qualificá-los com base em suas regras de filtragem, Adaptive Applications autorizadas podem ser informadas sobre a presença de um evento qualificado AUTOSAR_AP_EXP_SWArchitecture p. 123. Para isso, utiliza-se a classe [SWS_AIDSM_10800], que é instanciada por meio de seu construtor específico de porta [SWS_AIDSM_10801]. Após a chamada de Offer() [SWS_AIDSM_10808], o IdsM encaminha notificações para a aplicação chamando o callback correspondente. Se dados não versionados estiverem disponíveis, a chamada é realizada via OnEventQualification com contexto opcional e timestamp opcional [SWS_AIDSM_10807]. Se houver dados de contexto versionados, o daemon atende à interface sobrecarregada [SWS_AIDSM_10810]. A notificação pode ser encerrada com StopOffer() [SWS_AIDSM_10809].

Diagrama de sequência: recepção de eventos de segurança qualificados por uma aplicação de reação via QualifiedEventsReceiver. Fontes: AUTOSAR_AP_EXP_SWArchitecture p. 123, [SWS_AIDSM_10801], [SWS_AIDSM_10808], [SWS_AIDSM_10807].

Para o controle dinâmico do comportamento de notificação por evento, existe a classe [SWS_AIDSM_10600], que é inicializada por meio do construtor [SWS_AIDSM_10601]. Por meio de GetReportingMode, é possível consultar o modo atual para um ID de evento do tipo [SWS_AIDSM_10205] [SWS_AIDSM_10602]. Mediante SetReportingMode, o modo pode ser modificado em tempo de execução [SWS_AIDSM_10603]. A enumeração [SWS_AIDSM_10207] define os modos disponíveis, que variam desde a desativação completa (kOff), passando pelo registro padrão e detalhado (kBrief, kDetailed), até o desvio direcionado de cadeias de filtros internas (kBriefBypassingFilters, kDetailedBypassingFilters) [SWS_AIDSM_10207].

Diagrama de estados: modos de notificação e filtragem do processamento de eventos de acordo com ReportingModeType. Fontes: [SWS_AIDSM_10207], [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Modelagem de manifesto, vinculação de portas e deployment

A integração de todas as interfaces no sistema geral ocorre de forma declarativa por meio do manifesto AUTOSAR. Todas as interfaces de porta relacionadas ao IdsM derivam no metamodelo da classe base comum IdsmAbstractPortInterface AUTOSAR_AP_TPS_ManifestSpecification p. 257. O reporting é modelado por meio de um SecurityEventReportInterface, que é associado a uma SecurityEventDefinition formal por meio de um SecurityEventReportToSecurityEventDefinitionMapping AUTOSAR_AP_TPS_ManifestSpecification p. 146. Esse desacoplamento explícito permite reutilizar componentes de software padronizados e atribuir IDs de eventos específicos do projeto apenas no nível de configuração TPS_ManifestSpecification p. 146.

No nível de deployment, os diversos providers e receivers são mapeados como UploadableDeploymentElement TPS_ManifestSpecification p. 881. Entre eles incluem-se IdsmTimestampProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 664, IdsmContextProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 665, IdsmReportingModeProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 667 bem como IdsmQualifiedEventReceiverMapping AUTOSAR_AP_TPS_ManifestSpecification p. 669. Essas metaclasses vinculam a instância modular da plataforma IdsPlatformInstantiation ao respectivo processo (Process) e à porta de destino (PPortPrototype ou RPortPrototype) TPS_ManifestSpecification p. 664. Para clusters funcionais, existe ainda um mapeamento especial FunctionalClusterToSecurityEventDefinitionMapping para atribuir eventos de plataforma sem vinculação direta a processos de acordo com as normas AUTOSAR_AP_TPS_ManifestSpecification p. 873.

Comportamento em caso de falha e tratamento de diagnóstico

Situações de erro dentro do módulo IdsM são tratadas de acordo com o conceito padronizado de tratamento de erros do AUTOSAR por meio do domínio de erros [SWS_AIDSM_10706]. Este é referenciado por meio da função global GetIdsmErrorDomain() [SWS_AIDSM_10702]. Erros concretos da API são representados pela enumeração [SWS_AIDSM_10204] (alias [SWS_AIDSM_10707]). Se, por exemplo, ocorrer um ID de evento desconhecido ao consultar ou definir um modo de reporting, as operações GetReportingMode e SetReportingMode retornam um ara::core::Result com erro contendo o código IdsmErrc::kUnknownEventId [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Para a conversão em objetos de erro estruturados, utiliza-se a função auxiliar MakeErrorCode [SWS_AIDSM_10703]. O domínio de erros implementa as interfaces para consulta do nome do domínio [SWS_AIDSM_10710] bem como da mensagem de texto descritiva [SWS_AIDSM_10711]. Desde que exceções estejam ativadas no sistema, um código de erro pode ser lançado via ThrowAsException [SWS_AIDSM_10712] como exceção do tipo [SWS_AIDSM_10704] (alias [SWS_AIDSM_10708]), cujo construtor encapsula o ErrorCode subjacente [SWS_AIDSM_10705].

Comprovações detalhadas adicionais e referência à especificação

A compilação a seguir resume os principais documentos de especificação e pontos de arquitetura do módulo:

• Ingresso de eventos e reporting de sensores: As especificações [SWS_AIDSM_10101] e [SWS_AIDSM_10302] a [SWS_AIDSM_10307] definem a assinatura C++ de EventReporter. A integração arquitetural por sensores de plataforma é apresentada em AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13 e AUTOSAR_AP_EXP_SWArchitecture p. 121.
• Integração interna da plataforma: As dependências e padrões de uso de outros clusters funcionais, como Communication Management (AUTOSAR_AP_SWS_CommunicationManagement p. 34), Firewall (AUTOSAR_AP_SWS_Firewall p. 11) e Diagnostic Management (AUTOSAR_AP_SWS_Diagnostics p. 67), comprovam a função universal do IdsM como coletor de segurança.
• Providers de dados adicionais e de timestamps: As especificações [SWS_AIDSM_10400] e [SWS_AIDSM_10500] regulam o padrão de disponibilização para timestamps e modificações de contexto, complementadas pelo diagrama de arquitetura AUTOSAR_AP_EXP_SWArchitecture p. 122.
• Recepção de eventos qualificados e modos de operação: Os requisitos [SWS_AIDSM_10800] e [SWS_AIDSM_10600] descrevem a comunicação de egresso e a configuração em tempo de execução, ilustradas em AUTOSAR_AP_EXP_SWArchitecture p. 123.
• Modelagem de manifesto e de deployment: As regras do metamodelo em AUTOSAR_AP_TPS_ManifestSpecification p. 257, bem como os mapeamentos de deployment AUTOSAR_AP_TPS_ManifestSpecification p. 664 a AUTOSAR_AP_TPS_ManifestSpecification p. 669, asseguram a instanciação e a conexão consistentes no momento do projeto e do carregamento.
• Tratamento de erros: As definições [SWS_AIDSM_10204] e [SWS_AIDSM_10706] constituem a base do tratamento de erros em caso de identificadores de eventos inválidos.