module ara::idsm — Intrusion Detection System Manager

En tant que service central de la plateforme, l'Intrusion Detection System Manager acquiert les événements pertinents pour la sécurité provenant des clusters fonctionnels et des applications via des instances standardisées de la classe [SWS_AIDSM_10101] AUTOSAR_AP_EXP_SWArchitecture p. 124. Les messages entrants peuvent être enrichis d'horodatages et de données de contexte, filtrés et transmis à des récepteurs autorisés en tant qu'événements de sécurité qualifiés [SWS_AIDSM_10800]. Le raccordement de l'ensemble des interfaces et des ID d'événements requiert une modélisation cohérente via le manifeste AUTOSAR AUTOSAR_AP_TPS_ManifestSpecification p. 257.

plus ›

L'Intrusion Detection System Manager (IdsM) agit au sein de l'AUTOSAR Adaptive Platform en tant que Functional Cluster central basé sur un démon, dédié à l'agrégation, au filtrage et à l'évaluation des événements pertinents pour la sécurité AUTOSAR_AP_EXP_PlatformDesign p. 95. Les clusters fonctionnels tels que Communication Management, Firewall et Diagnostic Management, ainsi que les composants spécifiques à l'application, signalent les incidents de sécurité à l'IdsM de manière sûre au niveau des threads (thread-safe) via des instances standardisées de la classe [SWS_AIDSM_10101] AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

Diagramme de contexte : intégration du démon IdsM en tant que puits central pour les événements de sécurité provenant des clusters fonctionnels et des applications. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13.

Le signalement d'événements via ReportEvent prend en charge des niveaux de détail variables, allant de simples compteurs à des données de contexte non versionnées ou versionnées, en passant par des horodatages explicites [SWS_AIDSM_10302], [SWS_AIDSM_10307]. Pour un enrichissement dynamique, les applications peuvent être intégrées via [SWS_AIDSM_10400] et [SWS_AIDSM_10500] en tant que fournisseurs d'horodatages ou d'octets de contexte supplémentaires AUTOSAR_AP_EXP_SWArchitecture p. 122. Après évaluation des chaînes de filtrage internes, l'IdsM transmet les événements qualifiés aux récepteurs enregistrés via des callbacks de notification de la classe [SWS_AIDSM_10800] [SWS_AIDSM_10807].

Diagramme de séquence : signalement synchrone d'un événement de sécurité par un composant capteur via EventReporter. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101].

La configuration des ports et l'association des définitions d'événements s'effectuent via des éléments standardisés du métamodèle dans le manifeste AUTOSAR_AP_TPS_ManifestSpecification p. 257. Le comportement de signalement des différents événements peut en outre être contrôlé à l'exécution via [SWS_AIDSM_10600], les ID d'événements non valides étant signalés via le domaine d'erreur [SWS_AIDSM_10706] avec le code d'erreur kUnknownEventId [SWS_AIDSM_10204], [SWS_AIDSM_10602].

plus ›

Rôle et limites système de l'Intrusion Detection System Manager

L'Intrusion Detection System Manager (IdsM) constitue l'instance centrale de la plateforme pour l'acquisition, le préfiltrage et la qualification des événements pertinents pour la sécurité (Security Events) sur une AUTOSAR Adaptive Platform AUTOSAR_AP_EXP_PlatformDesign p. 95. Conformément aux exigences de cybersécurité de l'ISO/SAE 21434, l'IdsM fonctionne sur les calculateurs basés sur POSIX sous la forme d'un service d'arrière-plan autonome (daemon-based Functional Cluster) AUTOSAR_AP_EXP_SWArchitecture p. 124. Sa mission principale consiste à collecter les anomalies et les tentatives d'attaque potentielles, à les évaluer à l'aide de règles configurées telles que la limitation de débit ou des valeurs de seuil, et à les fusionner en événements de sécurité qualifiés (Qualified Security Events) AUTOSAR_EXP_SWArchitecture p. 97.

L'architecture de l'IdsM est conçue pour l'interopérabilité avec d'autres clusters fonctionnels. Des services de plateforme tels que Communication Management AUTOSAR_AP_SWS_CommunicationManagement p. 34, Firewall AUTOSAR_AP_SWS_Firewall p. 11 et Diagnostic Management AUTOSAR_AP_SWS_Diagnostics p. 67 ainsi que des processus spécifiques à l'application agissent en tant que capteurs de sécurité AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13. La vue d'ensemble ci-après illustre l'intégration du démon IdsM dans l'environnement d'exécution de l'Adaptive Platform.

Diagramme de contexte : intégration du démon IdsM en tant que puits central pour les événements de sécurité provenant des clusters fonctionnels et des applications. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 124, AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13, AUTOSAR_AP_EXP_PlatformDesign p. 95.

Signalement d'événements via EventReporter et formes d'interaction

L'interface d'entrée principale pour la transmission d'incidents de sécurité est matérialisée par la classe [SWS_AIDSM_10101]. Une entité émettrice instancie cette classe en indiquant un port défini au moyen de ara::core::InstanceSpecifier, de manière sûre au niveau des threads, via le constructeur [SWS_AIDSM_10301]. La liaison avec le SecurityEventReportInterface défini dans le manifeste est ainsi établie AUTOSAR_AP_TPS_ManifestSpecification p. 257. La transmission proprement dite s'effectue via des variantes surchargées de la méthode synchrone ReportEvent, qui peuvent être exécutées chacune de manière sûre au niveau des threads [SWS_AIDSM_10302].

En fonction de la nature de l'événement et des données de capteur disponibles, l'interface propose des formes de signalement échelonnées. La méthode de base transmet uniquement un nombre de répétitions de type [SWS_AIDSM_10203] (valeur par défaut 1) sans métadonnées supplémentaires [SWS_AIDSM_10302]. Pour les opérations critiques en temps, un horodatage spécifique au capteur, de type [SWS_AIDSM_10202], peut être transmis directement [SWS_AIDSM_10303]. En outre, des données utiles immuables sous forme de span d'octets de type [SWS_AIDSM_10201] peuvent être transmises soit seules [SWS_AIDSM_10304], soit combinées à un horodatage [SWS_AIDSM_10305]. Pour les formats d'événements structurés, il existe des surcharges avec des données de contexte versionnées de type [SWS_AIDSM_10206], qui représentent une paire de valeurs composée d'un span de données de contexte et d'un indicateur de version de 16 bits [SWS_AIDSM_10306], éventuellement complétée par un horodatage explicite [SWS_AIDSM_10307].

Un scénario typique pour ce chemin de signalement est le rejet de paquets réseau non autorisés par la pile TCP/IP et la Firewall : le système d'exploitation signale les paquets bloqués au démon Firewall, qui appelle alors sans délai ReportEvent AUTOSAR_AP_EXP_SWArchitecture p. 232. Le diagramme de séquence suivant illustre ce processus de signalement synchrone.

Diagramme de séquence : signalement synchrone d'un événement de sécurité par un composant capteur via EventReporter. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 232, [SWS_AIDSM_10101], [SWS_AIDSM_10302].

Données de contexte étendues et horodatages via des interfaces de fournisseurs

Afin de ne pas surcharger les processus émetteurs avec des interrogations temporelles lourdes ou des informations de contexte statiques, l'architecture prend en charge une inversion de flux de contrôle via des interfaces de fournisseurs (provider) AUTOSAR_AP_EXP_SWArchitecture p. 122. Les applications peuvent agir en tant que fournisseurs de services d'horodatage en dérivant de la classe abstraite [SWS_AIDSM_10400]. Après l'instanciation via le constructeur [SWS_AIDSM_10401], l'application active le service avec Offer() [SWS_AIDSM_10408]. À partir de cet instant, l'IdsM peut, en cas de besoin, appeler la méthode virtuelle pure GetTimestamp() afin de demander la valeur temporelle actuelle [SWS_AIDSM_10407]. La mise à disposition se termine avec StopOffer() [SWS_AIDSM_10409].

De manière analogue, la classe de base [SWS_AIDSM_10500] permet l'enrichissement dynamique ou la modification des données de contexte. Outre le InstanceSpecifier, le constructeur attend l'indication de la taille des octets supplémentaires ainsi que le décalage (offset) pour les données de contexte d'origine [SWS_AIDSM_10501]. Après libération par Offer() [SWS_AIDSM_10507], le démon IdsM appelle la méthode ModifyContextData lors de la réception d'un événement [SWS_AIDSM_10509]. À cette occasion, un span d'octets accessible en écriture est transmis, dans lequel l'application écrit des données modifiées avant de renvoyer la taille de données résultante sous la forme ara::core::Result<std::size_t> [SWS_AIDSM_10509]. La réception d'autres demandes de modification est désactivée avec StopOffer() [SWS_AIDSM_10508].

Diagramme de séquence : cycle de vie et déroulement de l'inversion de contrôle lors de l'enrichissement d'événements de sécurité via TimestampProvider et ContextDataProvider. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 122, [SWS_AIDSM_10408], [SWS_AIDSM_10509].

Réception d'événements de sécurité qualifiés et contrôle de fonctionnement

Une fois que l'IdsM a traité les événements entrants et les a qualifiés sur la base de ses règles de filtrage, les Adaptive Applications autorisées peuvent être informées de la présence d'un événement qualifié AUTOSAR_AP_EXP_SWArchitecture p. 123. La classe [SWS_AIDSM_10800], instanciée via son constructeur spécifique au port, est utilisée à cette fin [SWS_AIDSM_10801]. Après l'appel de Offer() [SWS_AIDSM_10808], l'IdsM transmet les notifications à l'application en appelant le callback correspondant. Si des données non versionnées sont prêtes, l'appel s'effectue via OnEventQualification avec contexte optionnel et horodatage optionnel [SWS_AIDSM_10807]. Si des données de contexte versionnées sont présentes, le démon dessert l'interface surchargée [SWS_AIDSM_10810]. La notification peut être interrompue avec StopOffer() [SWS_AIDSM_10809].

Diagramme de séquence : réception d'événements de sécurité qualifiés par une application de réaction via QualifiedEventsReceiver. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 123, [SWS_AIDSM_10801], [SWS_AIDSM_10808], [SWS_AIDSM_10807].

Pour le contrôle dynamique du comportement de signalement par événement, il existe la classe [SWS_AIDSM_10600], qui est initialisée via le constructeur [SWS_AIDSM_10601]. Le mode actuel pour un ID d'événement de type [SWS_AIDSM_10205] peut être interrogé via GetReportingMode [SWS_AIDSM_10602]. Le mode peut être modifié à l'exécution au moyen de SetReportingMode [SWS_AIDSM_10603]. L'énumération [SWS_AIDSM_10207] définit les modes disponibles, qui vont de la désactivation complète (kOff) à la dérivation ciblée des chaînes de filtrage internes (kBriefBypassingFilters, kDetailedBypassingFilters), en passant par l'acquisition standard et détaillée (kBrief, kDetailed) [SWS_AIDSM_10207].

Diagramme d'états : modes de signalement et de filtrage du traitement d'événements selon ReportingModeType. Sources : [SWS_AIDSM_10207], [SWS_AIDSM_10602], [SWS_AIDSM_10603].

Modélisation de manifeste, liaison de ports et déploiement

L'intégration de l'ensemble des interfaces dans le système global s'effectue de manière déclarative via le manifeste AUTOSAR. Toutes les interfaces de port liées à l'IdsM dérivent, dans le métamodèle, de la classe de base commune IdsmAbstractPortInterface AUTOSAR_AP_TPS_ManifestSpecification p. 257. Le reporting est modélisé via un SecurityEventReportInterface, qui est relié à une SecurityEventDefinition formelle par l'intermédiaire d'un SecurityEventReportToSecurityEventDefinitionMapping AUTOSAR_AP_TPS_ManifestSpecification p. 146. Ce découplage explicite permet de réutiliser des composants logiciels standardisés et de n'associer les ID d'événements spécifiques au projet qu'au niveau de la configuration TPS_ManifestSpecification p. 146.

Au niveau du déploiement, les différents fournisseurs (providers) et récepteurs sont représentés sous forme de UploadableDeploymentElement TPS_ManifestSpecification p. 881. En font partie IdsmTimestampProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 664, IdsmContextProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 665, IdsmReportingModeProviderMapping AUTOSAR_AP_TPS_ManifestSpecification p. 667 ainsi que IdsmQualifiedEventReceiverMapping AUTOSAR_AP_TPS_ManifestSpecification p. 669. Ces métaclasses relient l'instance de plateforme modulaire IdsPlatformInstantiation au processus respectif (Process) et au port cible (PPortPrototype ou RPortPrototype) TPS_ManifestSpecification p. 664. Pour les clusters fonctionnels, il existe en outre un mappage spécial FunctionalClusterToSecurityEventDefinitionMapping permettant d'associer conformément aux normes des événements de plateforme sans liaison directe à un processus AUTOSAR_AP_TPS_ManifestSpecification p. 873.

Comportement en cas d'erreur et traitement du diagnostic

Les situations d'erreur au sein du module IdsM sont traitées selon le concept de gestion des erreurs standardisé d'AUTOSAR via le domaine d'erreur [SWS_AIDSM_10706]. Celui-ci est référencé via la fonction globale GetIdsmErrorDomain() [SWS_AIDSM_10702]. Les erreurs concrètes de l'API sont représentées par l'énumération [SWS_AIDSM_10204] (alias [SWS_AIDSM_10707]). Si, par exemple, un ID d'événement inconnu est rencontré lors de l'interrogation ou de la définition d'un mode de reporting, les opérations GetReportingMode et SetReportingMode renvoient un ara::core::Result en échec avec le code IdsmErrc::kUnknownEventId [SWS_AIDSM_10602], [SWS_AIDSM_10603].

La fonction d'assistance MakeErrorCode sert à la conversion en objets d'erreur structurés [SWS_AIDSM_10703]. Le domaine d'erreur implémente les interfaces permettant d'interroger le nom de domaine [SWS_AIDSM_10710] ainsi que le message textuel descriptif [SWS_AIDSM_10711]. Si les exceptions sont activées dans le système, un code d'erreur peut être levé via ThrowAsException [SWS_AIDSM_10712] sous la forme d'une exception de type [SWS_AIDSM_10704] (alias [SWS_AIDSM_10708]), dont le constructeur encapsule le ErrorCode sous-jacent [SWS_AIDSM_10705].

Justificatifs détaillés complémentaires et référence aux spécifications

Le récapitulatif ci-après résume les principaux documents de spécification et points d'architecture du module :

• Ingress d'événements et signalement par les capteurs : les spécifications [SWS_AIDSM_10101] et de [SWS_AIDSM_10302] à [SWS_AIDSM_10307] définissent la signature C++ de EventReporter. L'intégration architecturale par des capteurs de plateforme est présentée dans AUTOSAR_AP_SWS_IntrusionDetectionSystemManager p. 13 et AUTOSAR_AP_EXP_SWArchitecture p. 121.
• Intégration interne à la plateforme : les dépendances et les modèles d'utilisation d'autres clusters fonctionnels tels que Communication Management (AUTOSAR_AP_SWS_CommunicationManagement p. 34), Firewall (AUTOSAR_AP_SWS_Firewall p. 11) et Diagnostic Management (AUTOSAR_AP_SWS_Diagnostics p. 67) attestent du rôle universel de l'IdsM en tant que collecteur de sécurité.
• Fournisseurs de données complémentaires et d'horodatages : les spécifications [SWS_AIDSM_10400] et [SWS_AIDSM_10500] régissent le modèle de mise à disposition des horodatages et des modifications de contexte, complété par le schéma d'architecture AUTOSAR_AP_EXP_SWArchitecture p. 122.
• Réception d'événements qualifiés et modes de fonctionnement : les exigences [SWS_AIDSM_10800] et [SWS_AIDSM_10600] décrivent la communication d'egress et la configuration à l'exécution, illustrées dans AUTOSAR_AP_EXP_SWArchitecture p. 123.
• Modélisation du manifeste et du déploiement : les règles de métamodèle dans AUTOSAR_AP_TPS_ManifestSpecification p. 257 ainsi que les mappages de déploiement de AUTOSAR_AP_TPS_ManifestSpecification p. 664 à AUTOSAR_AP_TPS_ManifestSpecification p. 669 garantissent une instanciation et une liaison cohérentes au moment de la conception et du chargement.
• Gestion des erreurs : les définitions [SWS_AIDSM_10204] et [SWS_AIDSM_10706] constituent le fondement de la gestion des erreurs en cas d'identifiants d'événements non valides.